Should Inline be private in the private part of a package spec?

Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

The aspect notation of Ada 2012 lets me specify Inline as
an aspect giving a pragmatic hint to the compiler.
This hint is very near the declaration:

package P is

  procedure Op (X : T)
    with Inline;

end P;


Should the readers of a package spec be bothered with hints
to the compiler if these hints address optimization, or other
aspect of how to implement a subprogram?

The hint does not add to an understanding of what an operation
is to achieve, IMHO. This understanding is what I'd hope to
get from reading a spec. Alternatively,

package P is

  procedure Op (X : T);

private
  pragma Inline (Op);
end P;

still lets the reader take note of inlining, should they
be so inclined. Am I missing something?

Re: Should Inline be private in the private part of a package spec?

[Martin Krischik]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Georg Bauhaus schrieb:
> procedure Op (X : T) with Inline;

Well, it tells me that the function is ?probably? rather small and
suitable for a larger variety of optimisations.

Which in turn might stop me from applying the premature optimisation
anti-pattern ;-).

Regards

Martin
- -- 
Martin Krischik
mailto://krischik@users.sourceforge.net
https://sourceforge.net/users/krischik

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFQG+F9ijwKaHyem9cRAsk2AJ9u1V2Y6HwwO5fEVDyaniY5jDJn9gCcCw0f
lpVBCJGrpkh7mFy4diAZMEw=
=jkco
-----END PGP SIGNATURE-----

Re: Should Inline be private in the private part of a package spec?

[Adam Beneschan]

On Friday, August 3, 2012 6:30:50 AM UTC-7, Georg Bauhaus wrote:
> The aspect notation of Ada 2012 lets me specify Inline as
> an aspect giving a pragmatic hint to the compiler.
> This hint is very near the declaration:
> 
> package P is
> 
>   procedure Op (X : T)
>     with Inline;
> 
> end P;
> 
> Should the readers of a package spec be bothered with hints
> to the compiler if these hints address optimization, or other
> aspect of how to implement a subprogram?
> 
> The hint does not add to an understanding of what an operation
> is to achieve, IMHO. This understanding is what I'd hope to
> get from reading a spec. Alternatively,
> 
> package P is
>
>   procedure Op (X : T);
>
> private
>   pragma Inline (Op);
> end P;
> 
> still lets the reader take note of inlining, should they
> be so inclined. Am I missing something?

I share your concern.  I sent something to Ada-Comment about this in June 2011, expressing this concern about making the pragmas "obsolescent"; here's part of Randy's response:

# I don't believe that either Inline or Import should be hidden in the private
# part, because both have (subtle) semantic effects that potentially break
# privacy. In particular, inline adds dependencies that might make linking a
# program impossible. (I don't think inline should be allowed to do that,
# either, but that's the way it is.) Import usually requires parameters that
# also have convention C -- it's rarely possible to hide the *entire* thing.

# It's better to hide Import and all of the convention C stuff in a private
# package . . .

Randy also thought it was better to encourage people to stop using the pragmas because using the pragmas on overloaded subprograms is problematic.  (And GNAT doesn't always get it right.  There are several examples of publicly available code that contain illegal Import pragmas on overloaded routines that GNAT didn't catch.  Another reason, I suppose, not to use them.)

Anyway, while I'm with you that I don't want a reader to have to see stuff like this in the package spec, at least Ada is still way ahead of, say, Java or C# in that regard; if I'm not confused, you have to put the whole body of the function right by the point where it's first declared, not just a small hint to the compiler.  Also, since we now have GUIs to work with programs instead of just punch cards and printouts, it's easy to envision a GUI displaying "compiler hints" like this in a lighter color, so that a reader looking at the package spec  because he wants to know how to use the package can focus on the important parts.

                        -- Adam 

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Fri, 03 Aug 2012 15:30:50 +0200, Georg Bauhaus wrote:

> The aspect notation of Ada 2012 lets me specify Inline as
> an aspect giving a pragmatic hint to the compiler.
> This hint is very near the declaration:
> 
> package P is
> 
>   procedure Op (X : T)
>     with Inline;
> 
> end P;
> 
> 
> Should the readers of a package spec be bothered with hints
> to the compiler if these hints address optimization, or other
> aspect of how to implement a subprogram?
> 
> The hint does not add to an understanding of what an operation
> is to achieve, IMHO. This understanding is what I'd hope to
> get from reading a spec. Alternatively,
> 
> package P is
> 
>   procedure Op (X : T);
> 
> private
>   pragma Inline (Op);
> end P;
> 
> still lets the reader take note of inlining, should they
> be so inclined. Am I missing something?

Yep. The concept of an aspect in general, not only inlining, looks
suspicious. The litmus question is whether the aspect describes something
functional. If it does not, it does not belong to public declarations and
any declaration, probably.

I doubt that anybody could argue that aspects represent anything "material"
to augment the existing set "things" like operation, type, object, package
(module), value.

A syntax motivated hack, maybe a language design flaw, though it is too
early to say right now.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Robert A Duff]

Adam Beneschan <adam@irvine.com> writes:

> # I don't believe that either Inline or Import should be hidden in the private
> # part, because both have (subtle) semantic effects that potentially break
> # privacy. In particular, inline adds dependencies that might make linking a
> # program impossible.

I don't think that's right.  Inline doesn't add dependencies.

>...(I don't think inline should be allowed to do that,
> # either, but that's the way it is.)

I don't think inline should be allowed to do that, either
-- fortunately, that's not the way it is.  ;-)

If you (Randy) don't agree, please quote chapter&verse.

I just tried the following example, which has mutually-recursive
inlining, and gnat didn't have any trouble compiling it or
linking it.  I think that's required -- a compiler would be
wrong to say this example is illegal.

  package P1 is
     procedure Proc1 with Inline;
     procedure Proc2 with Inline;
  end P1;

  with Text_IO; use Text_IO;
  with P2;
  package body P1 is
     procedure Proc1 is
     begin
        Put_Line ("Proc1");
     end Proc1;

     procedure Proc2 is
     begin
        P2.Proc2;
     end Proc2;
  end P1;

  package P2 is
     procedure Proc1 with Inline;
     procedure Proc2 with Inline;
  end P2;

  with Text_IO; use Text_IO;
  with P1;
  package body P2 is
     procedure Proc1 is
     begin
        P1.Proc1;
     end Proc1;

     procedure Proc2 is
     begin
        Put_Line ("Proc2");
     end Proc2;
  end P2;

  with P1, P2;
  procedure Main is
  begin
     P1.Proc2;
     P2.Proc1;
  end Main;

- Bob

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcc4noj4zof.fsf@shell01.TheWorld.com...
> Adam Beneschan <adam@irvine.com> writes:
>
>> # I don't believe that either Inline or Import should be hidden in the 
>> private
>> # part, because both have (subtle) semantic effects that potentially 
>> break
>> # privacy. In particular, inline adds dependencies that might make 
>> linking a
>> # program impossible.
>
> I don't think that's right.  Inline doesn't add dependencies.
>
>>...(I don't think inline should be allowed to do that,
>> # either, but that's the way it is.)
>
> I don't think inline should be allowed to do that, either
> -- fortunately, that's not the way it is.  ;-)
>
> If you (Randy) don't agree, please quote chapter&verse.

We had this discussion on the ARG list ()last fall, I think), and we pretty 
much agreed that it could. (I don't think you ever agreed, but there's 
plenty of evidence in the RM - I'm not going to waste my time looking it up 
again. You didn't believe the evidence that was presented last time, but you 
were clearly wrong then and you still are. :-)

Certainly with a "conventional" compiler like Janus/Ada, a body can be out 
of sync with a specification, and inline creates a dependence on the body 
that doesn't exist before - that's guarenteed to cause problems.

> I just tried the following example, which has mutually-recursive
> inlining, and gnat didn't have any trouble compiling it or
> linking it.  I think that's required -- a compiler would be
> wrong to say this example is illegal.

It's not illegal, it fails to link. That's pretty different! (Everyone else: 
sorry, this is language-lawyer talk.)

Anyway, inline is a permission, and a compiler can ignore it. But if it 
doesn't ignore it, it causes additional dependences.
In any case, I don't see why you think it is relevant when it clearly 
depends on the compiler. (GNAT never pre-compiles specifications, so I don't 
think you could ever see one of these dependencies in a way that prevented 
linking. But it's easy in other compilers)

                                                 Randy.

Re: Should Inline be private in the private part of a package spec?

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> We had this discussion on the ARG list ()last fall, I think), and we pretty 
> much agreed that it could. (I don't think you ever agreed, but there's 
> plenty of evidence in the RM - I'm not going to waste my time looking it up 
> again. You didn't believe the evidence that was presented last time, but you 
> were clearly wrong then and you still are. :-)

OK, I don't remember the details of that discussion.  You might be
right.  Or maybe I was right, and everybody else on ARG was wrong.
It wouldn't be the first time.  ;-)

I looked in the RM yesterday, and it says there are two types of
dependences, and it defines them pretty clearly, and Inline
doesn't figure into either one.

> It's not illegal, it fails to link.

If it's not illegal, then the implementation is required to
run it.  See RM-1.1.3:

1   A conforming implementation shall:

2     * Translate and correctly execute legal programs written in Ada,
        provided that they are not so large as to exceed the capacity of the
        implementation;

Or are you claiming that this Inline business falls under the
"exceed the capacity" loophole (which is admittedly a loophole
through which one could drive a truck)?

>... That's pretty different! (Everyone else: 
> sorry, this is language-lawyer talk.)

There's no "fails to link" in the RM.  There's a concept of
"legal" both for compilation units, and for entire programs.

Anyway, regardless of what the RM says, surely an optimization hint
like Inline shouldn't prevent a program from running properly.
Especially if it's implementation dependent.  That would be a
serious language design flaw.

If you like, show us an example of one of these "fails to link"
cases.  Or don't bother -- it's really not that important.

- Bob

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Robert A Duff <bobduff@shell01.theworld.com> писал(а) в своём письме Mon,  
06 Aug 2012 18:33:42 +0400:

> "Randy Brukardt" <randy@rrsoftware.com> writes:
>

> If you like, show us an example of one of these "fails to link"
> cases.  Or don't bother -- it's really not that important.


Perhaps Randy mentioned linking (binding object files). In a case when you  
make subprogram inlined then to effective figure out it in resulting image  
you should *recompile*, rebuild and relink modules that have used this  
subprogram previously, into a new application image (entirely). This means  
in a nut that subprogram changed its specification cardinally from 'call'  
to 'jump' and a method of passing its parameters from callers is changed  
accordingly.

So indeed 'inlining' belongs to subprogram specification in the same way  
as calling convention.

I suppose that language syntax should (shall, must, have to, used to be)  
support subprogram specification and its properties as one atomic unit, so  
ordinary developer (syntax enabled IDE or automated tool) can copy  
subprogram specification text without doubt "is anything else he/she  
forgot to dig in the source about this specification".

E.g. this means that the best way is to see subprogram specification as  
one language sentence.



-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 06.08.12 17:50, Vasiliy Molostov wrote:
> Robert A Duff <bobduff@shell01.theworld.com> писал(а) в своём письме Mon, 06
> Aug 2012 18:33:42 +0400:
> 
>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>
> 
>> If you like, show us an example of one of these "fails to link"
>> cases.  Or don't bother -- it's really not that important.
> 
> 
> Perhaps Randy mentioned linking (binding object files). In a case when you
> make subprogram inlined then to effective figure out it in resulting image you
> should *recompile*, rebuild and relink modules that have used this subprogram
> previously, into a new application image (entirely). This means in a nut that
> subprogram changed its specification cardinally from 'call' to 'jump'

The subprogram specification does not change, even when
the compiler chooses to produce different output.

The competing ways of saying "inline" are both in a package spec.
One is private, the other needs to be listed among other aspects of
the public spec of a subprogram.


> So indeed 'inlining' belongs to subprogram specification in the same way as
> calling convention.

Inlining and convention are aspects typically related to translation,
aspects that would not normally affect the resulting
executable program except in the way that, say,
optimization switches do. Optimization switches are not usually
part of subprogram's public specifications either. So why
should inline need to be in the public view of a subprogram's spec?

When you c&p a subprogram's spec, when is that? Why should
aspects like Inline or Convention be part of the copy,
which is not to be the original for a reason?

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Mon,  
06 Aug 2012 21:58:25 +0400:

> On 06.08.12 17:50, Vasiliy Molostov wrote:
>> Robert A Duff <bobduff@shell01.theworld.com> писал(а) в своём письме  
>> Mon, 06
>> Aug 2012 18:33:42 +0400:
>>
>>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>>

>> So indeed 'inlining' belongs to subprogram specification in the same  
>> way as
>> calling convention.
>
> Inlining and convention are aspects typically related to translation,
> aspects that would not normally affect the resulting
> executable program except in the way that, say,
> optimization switches do.

They will affect already compiled modules. As you might know Ada aimed to  
minimize recompilations.
It is the common thing and one of major reasons why
ada has so much of the stuff with these visibilities and packages.

Why you have decided that calling convention is an optinization?

> Optimization switches are not usually
> part of subprogram's public specifications either.

Why (convention) is not a part? What is usually?
Yesterday I wrote some code and it has specs along with inline, just after  
subprogram spec.
Today you said that it is not usual. Not usual for whom?

> So why
> should inline need to be in the public view of a subprogram's spec?

Because it is a part of the specification. both of them convention and  
inline are
not optimisation, but code representation.

My choice is to see this as a part of specification. Much convenient.


> When you c&p a subprogram's spec, when is that?

When I use UML generator and wish to output subprogram specification and  
its properties
(e.g. inlining or convention) be printed in one pass (line, stanza,  
sentence).

> Why should
> aspects like Inline or Convention be part of the copy,
> which is not to be the original for a reason?

What is an original? Its unclear.

The way that usual works fine is to add brick or remove it. Since the  
brick is atomic element.

You are asking about how to get two bricks instead of one - a common brick  
and a small which is a supplement to the first one, being placed somewhere  
else in a private part.
And operations you offer are - add one, and then add its extent, searching  
appropriate place. And otherwise - remove common, and then searching its  
extent somewhere else.

What is the profit? It costs to much but I do not see any profit.

A good way is to use Inline as a configuration pragma, which will be  
processed along with other stuff like elimination of unused code. And of  
sourse, only if it is possible to inline, since library developer can  
enable/disable this, as Randy said - its a permission to the compiler to  
inline a subprogram.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 06.08.12 23:01, Vasiliy Molostov wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Mon, 06 Aug 2012 21:58:25 +0400:
>
>> On 06.08.12 17:50, Vasiliy Molostov wrote:
>>> Robert A Duff <bobduff@shell01.theworld.com> писал(а) в своём письме Mon, 06
>>> Aug 2012 18:33:42 +0400:
>>>
>>>> "Randy Brukardt" <randy@rrsoftware.com> writes:
>>>>
>
>>> So indeed 'inlining' belongs to subprogram specification in the same way as
>>> calling convention.
>>
>> Inlining and convention are aspects typically related to translation,
>> aspects that would not normally affect the resulting
>> executable program except in the way that, say,
>> optimization switches do.
>
> They will affect already compiled modules.

That's not relevant to specifying subprograms in public parts
of a package spec. A subprogram spec is about how to write
correct calls of the public subprogram.

> As you might know Ada aimed to minimize recompilations.

Quality of implementation issue. I think Bob Duff has also explained
a few times that incremental compilation might would be a better
choice if minimizing recompilations is a goal.

> Why you have decided that calling convention is an optinization?

What the program does is not a matter of whether or not
some subprogram needs calling convention Ada or StdCall or
some such. Hence, from the perspective of the caller,
knowing the calling convention of an import is distraction
at best.

>> Optimization switches are not usually
>> part of subprogram's public specifications either.
>
> Why (convention) is not a part? What is usually?

I'd expect aspects to let me know what a subprogram does
if I call it with suitable parameters. Aspects of how that
is going to be done in terms of processor instructions
are of no concern at this point.

> Yesterday I wrote some code and it has specs along with inline, just after subprogram spec.
> Today you said that it is not usual. Not usual for whom?

The focus is on the public part of a package spec, to be read by
other programmers. Information hiding might ask for compiler
hints and the like to be put somewhere they do not clutter
the text that conveys meaning, that is, explains what a
subprogram does, and how to call it. Inline can well be hidden
here. Note that if Inline is in the private part of a package
spec, the compiler can still see it when compiling the spec
separately.

The possible inline status of a subprogram compiled by a certain
compiler controlled by a certain set of switches does not add to
the knowledge of how to write calls of the subprogram properly.


>> So why
>> should inline need to be in the public view of a subprogram's spec?
>
> Because it is a part of the specification. both of them convention and inline are
> not optimisation, but code representation.

Inline gives the compiler permission to inline a subprogram,
but it does not specify anything that a programmer needs to
know in order to call the subprogram.   The calls he or she writes
will be invariably the same, no matter what the inline status
will have turned into in some executable program.


> My choice is to see this as a part of specification. Much convenient.

Writers' convenience usually is a sign of less than co-operative
software design, pardon the expression. The focus is on readers'
convenience.


>> When you c&p a subprogram's spec, when is that?
>
> When I use UML generator and wish to output subprogram specification and its properties
> (e.g. inlining or convention) be printed in one pass (line, stanza, sentence).

When modelling, pragmatic hints seem all the more irrelevant.
When a UML tool starts to dictate how package specifications
should be made, I start to worry a little.


>> Why should
>> aspects like Inline or Convention be part of the copy,
>> which is not to be the original for a reason?
>
> What is an original? Its unclear.
>
> The way that usual works fine is to add brick or remove it. Since the brick is atomic element.
>
> You are asking about how to get two bricks instead of one - a common brick and a small which is a supplement to the first one, being placed somewhere else in a private part.
> And operations you offer are - add one, and then add its extent, searching appropriate place. And otherwise - remove common, and then searching its extent somewhere else.
>
> What is the profit? It costs to much but I do not see any profit.

When I pay a programmer of a package to write a package
that I can use, I couldn't care less about whether he or she
finds it profitable or convenient to have all aspects/pragmata
in one place. I want to be able to read the spec, learn about
how to call the subprograms, and be done.

When I write just the specification and the body should be
written by someone else, then it seems rather premature
to write Inline aspects and request that they be considered
just as much specification as the parameter types or expressions
from predicate calculus stating relations between them.
OTOH, if the writers of the body decide that one of the
subprograms might be expanded inline, they can add a pragma
(or brick, as you say) as needed *without* changing the
specification of this subprogram.




> A good way is to use Inline as a configuration pragma,

Since Inline applies to program units, that won't work.
Moreover, pragma inline, if used heavily, can be counterproductive,
for example, if it makes register allocation be at odds with
the compiler's other ideas. For example, sometimes GCC's vectorizer
seems to require that a function *not* be inlined, in order to
increase overall speed of execution.

The library's developers can only disable inlining if they
removes pragma Inline / aspects, or if the tool chain can be
incapacitated in other ways.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 06.08.12 23:52, Georg Bauhaus wrote:

>> Why you have decided that calling convention is an optinization?
>
> What the program does is not a matter of whether or not
> some subprogram needs calling convention Ada or StdCall or
> some such. Hence, from the perspective of the caller,
> knowing the calling convention of an import is distraction
> at best.

And, just like it is not normally important to know optimization
issues when writing a call, it is not important to know
the convention of an import when writing the call (of the
Ada subprogram from the package spec). This is why I have
likened optimization to calling conventions. They share the
same degree of irrelevance from the caller's perspective.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue,  
07 Aug 2012 01:52:34 +0400:


>> They will affect already compiled modules.
>
> That's not relevant to specifying subprograms in public parts
> of a package spec. A subprogram spec is about how to write
> correct calls of the public subprogram.

BTW, I have menant the same - modules that have used this inlined  
subprogram and already compiled.

>> As you might know Ada aimed to minimize recompilations.
>
> Quality of implementation issue. I think Bob Duff has also explained
> a few times that incremental compilation might would be a better
> choice if minimizing recompilations is a goal.

? I dont see your replica is related to recompilation and inlining.

>> Why you have decided that calling convention is an optinization?
>
> What the program does is not a matter of whether or not
> some subprogram needs calling convention Ada or StdCall or
> some such. Hence, from the perspective of the caller,
> knowing the calling convention of an import is distraction
> at best.

Caller should be possible to establish any property to link this  
subprogram to its own image (link it from a library or from a standalone  
compiled module).
If not - linking is not possible.


>>> Optimization switches are not usually
>>> part of subprogram's public specifications either.
>>
>> Why (convention) is not a part? What is usually?
>
> I'd expect aspects to let me know what a subprogram does
> if I call it with suitable parameters. Aspects of how that
> is going to be done in terms of processor instructions
> are of no concern at this point.

Unclear, or I cannot see any relation to convention/inlining.
What are you about? Rook gambits are tied?

>> Yesterday I wrote some code and it has specs along with inline, just  
>> after subprogram spec.
>> Today you said that it is not usual. Not usual for whom?
>
> The focus is on the public part of a package spec, to be read by
> other programmers. Information hiding might ask for compiler
> hints and the like to be put somewhere they do not clutter
> the text that conveys meaning, that is, explains what a
> subprogram does, and how to call it. Inline can well be hidden
> here.

The question was - WHY? And for what benefit?

> Inline gives the compiler permission to inline a subprogram,
> but it does not specify anything that a programmer needs to
> know in order to call the subprogram.   The calls he or she writes
> will be invariably the same, no matter what the inline status
> will have turned into in some executable program.

No, when I call inlined subprogram I can see that this is inlined and I  
can not use hardware breakpoint, I can not use address of such subprogram  
widely in my writings, and I can suppose that internal variables if they  
are shared across inlined copies can cause a jam with locals, and I can  
not use it as an interrupt handler. From other properties I can take more  
assumptions what can be inserted in my code.

> Writers' convenience usually is a sign of less than co-operative
> software design, pardon the expression. The focus is on readers'
> convenience.

By that reader I mean not only human, but also a compiler, a tool for UML  
processing, and the rest. I think that your approach is entirely against  
cooperation. Sabotage.

> When modelling, pragmatic hints seem all the more irrelevant.
> When a UML tool starts to dictate how package specifications
> should be made, I start to worry a little.

Seem for whom? your words sound like stylist, and not a designer. Me  
dictate to my UML tool what to be made.
So you should not be worry even a little, since it is not related to you.
The question was - why you have named 'convention' as one of optimizations?

> When I pay a programmer of a package to write a package
> that I can use, I couldn't care less about whether he or she
> finds it profitable or convenient to have all aspects/pragmata
> in one place. I want to be able to read the spec, learn about
> how to call the subprograms, and be done.

I suppose as you pay - you dont write them. Probably your way - is to pay  
for all
the program (and related subprograms) entirely, without making things  
stressed
for people (or tools) with which you dont share their convenience.

Buy ready to use thing - its much less nervous!

> When I write just the specification and the body should be
> written by someone else, then it seems rather premature
> to write Inline aspects and request that they be considered
> just as much specification as the parameter types or expressions
> from predicate calculus stating relations between them.

Indeed. Premature. If you design is weak and there is nothing to supply it  
is indeed premature to write aspects at all.

If you know what are you doing (and every contractor's requirement express  
such knowledge) - why not?

> OTOH, if the writers of the body decide that one of the
> subprograms might be expanded inline, they can add a pragma
> (or brick, as you say) as needed *without* changing the
> specification of this subprogram.

This is too serious action to add a brick without approval. Have you tried  
it on railroads?

How about Q&A team with their set of tests that meet some kind of such a  
small extention brick at testing stage?

>> A good way is to use Inline as a configuration pragma,
>
> Since Inline applies to program units, that won't work.

I have pointed out to pragma Eliminate.

> Moreover, pragma inline, if used heavily, can be counterproductive,
> for example, if it makes register allocation be at odds with
> the compiler's other ideas. For example, sometimes GCC's vectorizer
> seems to require that a function *not* be inlined, in order to
> increase overall speed of execution.
>
> The library's developers can only disable inlining if they
> removes pragma Inline / aspects, or if the tool chain can be
> incapacitated in other ways.

Do you plan to add here also excerpts from Yellow Pages? I have a copy,  
btw.

The question is still open: Why You have insist that convention is an  
optimisation?
-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue,  
07 Aug 2012 02:10:08 +0400:

> And, just like it is not normally important to know optimization
> issues when writing a call, it is not important to know
> the convention of an import when writing the call (of the
> Ada subprogram from the package spec).

It is important since we all here working with libraries of already  
compiled code. We need it.

> This is why I have
> likened optimization to calling conventions. They share the
> same degree of irrelevance from the caller's perspective.

What is the perspective of that caller you mean?


-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue,  
07 Aug 2012 01:52:34 +0400:

Probably, am not right being so peace-less motivated.

With your specification example, you could imagine several subprograms  
with different parameter specifications, but with the same name, which is  
most frequently used in Ada - text_io.put, open, close and similar names  
frequently used for different kind of subprograms doing similar things and  
those purpose is to keep caller's body (implementation) clear from  
close_pipe close_file (close_stream, value_from_string and etc)...

So you probably say about how to supply the same specification in its full  
qualified form twicely - in public and in private part, but in different  
ways and for different purpose.

So spec is indeed atomic and you can not simply divide it into independent  
parts.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 07.08.12 01:12, Vasiliy Molostov wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue, 07 Aug 2012 02:10:08 +0400:
>
>> And, just like it is not normally important to know optimization
>> issues when writing a call, it is not important to know
>> the convention of an import when writing the call (of the
>> Ada subprogram from the package spec).
>
> It is important since we all here working with libraries of already compiled code. We need it.

Frankly, if you are working with compiled libraries made for
re-use and your compiler's linking machinery cannot handle the
two typical setups that are representatives of this discussion,
viz. library-in-mode-optimal and library-in-mode-debugging,
then maybe switch compilers but don't put all kinds of program-
specific, compiler-specific, debugger-specific stuff in a public
package spec. That's your quality of implementation problem with
your tools, not the readers of specs of re-usable packages and
that's my point.

Example:
...
Ada.Strings.Fixed.Move (...);
...

So we have a user of package Ada.Strings.Fixed who wishes to know about
Ada's Move. Would he normally have to learn---if A.S.Fixed has been compiled
already---certain aspects related to translation and debugging for
some implementation for some processors for some program?
No! He should be able to write Move and know what Move does.
Should he be able to learn about optimization opportunities
when Move becomes part of some important inner loop?
Yes! For example, he should be able to see whether or not
Move can be inlined.  But this case is special and, being a special case,
should not clutter the specification of Move in Ada.Strings.Fixed!



>> This is why I have
>> likened optimization to calling conventions. They share the
>> same degree of irrelevance from the caller's perspective.
>
> What is the perspective of that caller you mean?

Oh, well, the standard perspective of the scenario Ada was made for:

Larger pieces of software built independently such that team A
using package P1, and unrelated team B also using package P1,
in unrelated programs Prog_X13 and Prog_Z24 need not normally
know about internals of P1, or about how P1 was translated for
team B (whom they likely never heard of), or about how P1.Sub_98
is called by team A's Prog_X13, but not called in the same way
by team B's Prog_Z24. Or what compiler might be used and whether
or not P1.Sub_98 cannot be inlined in version 1.23 of compiled
distribution of P1 for teams C, D, but not for team E.

These questions are interesting in specific situations, but
they should not intrude the specification of public P1.Sub_98.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 07.08.12 01:09, Vasiliy Molostov wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue, 07 Aug 2012 01:52:34 +0400:
>
>
>>> They will affect already compiled modules.
>>
>> That's not relevant to specifying subprograms in public parts
>> of a package spec. A subprogram spec is about how to write
>> correct calls of the public subprogram.
>
> BTW, I have menant the same - modules that have used this inlined subprogram and already compiled.
>
>>> As you might know Ada aimed to minimize recompilations.
>>
>> Quality of implementation issue. I think Bob Duff has also explained
>> a few times that incremental compilation might would be a better
>> choice if minimizing recompilations is a goal.
>
> ? I dont see your replica is related to recompilation and inlining.

Advances in compiler technology, or even varying the
compilation processes, should not find a way into
public parts of public packages made for re-use by others.

package Reusable is

   procedure Op (X : T)
      with Inline => True,
           Optimize => Time,
        GNAT_Eliminate => Possibly,
       Rational_Debug_Hook => Yes,
        SofCheck_Inspectable => X;

That's all relevant information in some hypothetical
specific setup, but it is terribly at odds with re-usable Ada.
These aspect are pragmatic, they are not relevant for re-use,
they are extrinsic to Op's meaning.

Notice the signal to noise ratio in LOC when comparing
the lines that inform about the meaning of Op and the
lines that inform about aspects relating to tools and
translation.

A better place would be Bob Duff's idea of a third
file also collecting the representation information.

> What are you about? Rook gambits are tied?

I can call X if I supply proper arguments to X.
Everything else is not normally relevant in order for
me to know the meaning of my program that calls X.

>> Inline can well be hidden here.
>
> The question was - WHY? And for what benefit?

For the benefit of the reader who is concerned with
what his program does when calling X, irrespective
of anything to do with translation, or quality of
the compiler, or distribution format of libraries.


> No, when I call inlined subprogram I can see that this is inlined and I can not use hardware breakpoint, I can not use address of such subprogram widely in my writings, and I can suppose that internal variables if they are shared across inlined copies can cause a jam with locals, and I can not use it as an interrupt handler. From other properties I can take more assumptions what can be inserted in my code.

These are aspects of optimization and debugging,
not aspect of the meaning of the program.
Why would I want to learn about your debugging preferences
when all I want to know is how to call your subprogram properly?

If I do want to know how to optimize, or how to link
some unfortunate library distribution, the necessary information
could be provided in its proper place, which I think is not
what the subprogram is generally about.

>> Writers' convenience usually is a sign of less than co-operative
>> software design, pardon the expression. The focus is on readers'
>> convenience.
>
> By that reader I mean not only human, but also a compiler, a tool for UML processing, and the rest. I think that your approach is entirely against cooperation. Sabotage.

Writing for the compiler is o.K. if tuning a specific
program. However, when writing public parts of packages
for use by others, your compilers and tools do not count.
Not at all. Not in Ada.

  
>> When modelling, pragmatic hints seem all the more irrelevant.
>> When a UML tool starts to dictate how package specifications
>> should be made, I start to worry a little.
>
> Seem for whom?

Seem irrelevant for the one who models: Note that modelling is
different from programming in that the model abstracts things
away that---by the strict definition of modelling---you do care
about when writing whole programs in a programming language,
but not in a modelling language. Otherwise, the two would be
the same.

I know that some want to write programs using graphical
languages. That's not Ada, then, and Ada's principles cannot
apply, otherwise everyone would be writing Ada, not be
manipulating UML diagrams.

> your words sound like stylist, and not a designer. Me dictate to my UML tool what to be made.
> So you should not be worry even a little, since it is not related to you.

If what you do is not related to anyone but you,
why do you comment on what should be added to
specifications of publicly visible subprograms
in packages written for others?


> I suppose as you pay - you dont write them. Probably your way - is to pay for all
> the program

No, I usually get to use modules written by others.
It is always time consuming and costly if an interface appears
to be influenced by the coding habits, or library specifics,
or compiler specific, or version numbers, or tools used,
things to be associated with the writer only.


> Buy ready to use thing - its much less nervous!

Wishful thinking. More than once I have been stopped
by aspects / pragmas that have nothing to do with the arguments
to use when calling a subprogram. For example,

pragma Linker_Options

written by a "cool, pragmatic writer" gets very much in
the way of using packages, all the more when you cannot change
its string argument, or even just comment the dreadful thing!
Pragmas/aspects like these should not be used in re-usable
software!

Ideally, Inline should be easily controllable outside
the source text proper. Again, maybe in a third file that also
has the representation information.

Then, both the supplier and the client of a package could
control aspects like inline that are not intrinsic to
a subprogram. The third file could be switched, everyone
is happy and subprogram specification are not littered
with aspects of specific translations.

> If you know what are you doing (and every contractor's requirement express such knowledge) - why not?

Because everyone-knows-everything and everyone-is-using-the-same-setup
is very un-Ada. It makes software less re-usable.


> This is too serious action to add a brick without approval. Have you tried it on railroads?

I write software, I don't mess with railroads.

Since pragma Inline does not---allusions to anecdotal evidence
not withstanding---change the meaning of a subprogram, adding it
does not change the meaning of the program that calls the subprogram.
Specifying inline is thus not different from switching to higher
optimization, or from upgrading the compiler.
Which is being done carefully (Q&A), but is being done.

>>> A good way is to use Inline as a configuration pragma,
>>
>> Since Inline applies to program units, that won't work.
>
> I have pointed out to pragma Eliminate.

Pragma Eliminate is GNAT specific.  How does this add to the
meaning of subprograms in terms of Ada? What is the best place of a
compiler specific pragma if the goal should be to write for readers who
want to understand how to call a subprogram? I say, the best place is
outside the source code proper.


> The question is still open: Why You have insist that convention is an optimisation?

As mentioned in another post, I have likened the convention
of an import to optimization in the following way:
It is simply not relevant to know the import status of
a subprogram in order to call it, just like it is not relevant
to know its optimization in order to call it.
The meaning does not change, pragmatic aspects will.

Hence, the place where others want to learn how to call a
subprogram is not the place for aspects that apply in very
specific circumstances only. They never affect the text
of the call statement.

Re: Should Inline be private in the private part of a package spec?

[Simon Wright]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> On 06.08.12 23:01, Vasiliy Molostov wrote:
>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём
>> письме Mon, 06 Aug 2012 21:58:25 +0400:
>>
>>> When you c&p a subprogram's spec, when is that?
>>
>> When I use UML generator and wish to output subprogram specification
>> and its properties (e.g. inlining or convention) be printed in one
>> pass (line, stanza, sentence).
>
> When modelling, pragmatic hints seem all the more irrelevant.  When a
> UML tool starts to dictate how package specifications should be made,
> I start to worry a little.

If it's a good UML tool, you shouldn't need to look at the generated
package specs that often (you will know what they look like from looking
at the model). IMHO.

>> A good way is to use Inline as a configuration pragma,
>
> Since Inline applies to program units, that won't work.  Moreover,
> pragma inline, if used heavily, can be counterproductive, for example,
> if it makes register allocation be at odds with the compiler's other
> ideas. For example, sometimes GCC's vectorizer seems to require that a
> function *not* be inlined, in order to increase overall speed of
> execution.

Completely agree. We found (on powerpc-wrs-vxworks) that globally
inlining access subprograms (to return/update the value of a component
declared in a private part) increased the size and slowed the code. No
metrics, sorry.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue,  
07 Aug 2012 13:33:21 +0400:

> On 07.08.12 01:09, Vasiliy Molostov wrote:
.....
> Hence, the place where others want to learn how to call a
> subprogram is not the place for aspects that apply in very
> specific circumstances only. They never affect the text
> of the call statement.
>

Perhaps I am a bad reader but you have not explained - what the benefit to  
place Inline in a private part.

Why convention is an optimisation? <- "you still have unanswered question  
here"

Other things in your replacas while they are good in common I consider as  
demagogy here, sorry.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Simon Wright <simon@pushface.org> писал(а) в своём письме Tue, 07 Aug 2012  
14:01:27 +0400:

>>> A good way is to use Inline as a configuration pragma,
>>
>> Since Inline applies to program units, that won't work.  Moreover,
>> pragma inline, if used heavily, can be counterproductive, for example,
>> if it makes register allocation be at odds with the compiler's other
>> ideas. For example, sometimes GCC's vectorizer seems to require that a
>> function *not* be inlined, in order to increase overall speed of
>> execution.
>
> Completely agree. We found (on powerpc-wrs-vxworks) that globally
> inlining access subprograms (to return/update the value of a component
> declared in a private part) increased the size and slowed the code. No
> metrics, sorry.

I meant one of potential ways to apply Inline in a way similar to  
Eliminate which will satisfy "clean" configuration pragma approach - place  
all of them in one file and name it as configuration without dirtying  
source public or private part.

> (to return/update the value of a component
> declared in a private part)

But as I understand a question was to setup inlining pragma in a private  
part for a subprogram which is specified in a public part.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Simon Wright <simon@pushface.org> писал(а) в своём письме Tue, 07 Aug 2012  
14:01:27 +0400:

> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>
>> On 06.08.12 23:01, Vasiliy Molostov wrote:
>>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём
>>> письме Mon, 06 Aug 2012 21:58:25 +0400:
>>>
>>>> When you c&p a subprogram's spec, when is that?
>>>
>>> When I use UML generator and wish to output subprogram specification
>>> and its properties (e.g. inlining or convention) be printed in one
>>> pass (line, stanza, sentence).
>>
>> When modelling, pragmatic hints seem all the more irrelevant.  When a
>> UML tool starts to dictate how package specifications should be made,
>> I start to worry a little.
>
> If it's a good UML tool, you shouldn't need to look at the generated
> package specs that often (you will know what they look like from looking
> at the model). IMHO.

I doubt that any tool can be good enough, and use customized generator,  
and I found that changing generator can make a necessity to review what is  
generated, this greatly prevents UML tool from any dictate. I doubt that  
this process relate to modelling itself, btw.


-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 07.08.12 15:09, Vasiliy Molostov wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue, 07
> Aug 2012 13:33:21 +0400:
> 
>> On 07.08.12 01:09, Vasiliy Molostov wrote:
> .....
>> Hence, the place where others want to learn how to call a
>> subprogram is not the place for aspects that apply in very
>> specific circumstances only. They never affect the text
>> of the call statement.
>>
> 
> Perhaps I am a bad reader but you have not explained - what the benefit to
> place Inline in a private part.


Premise 1: The reader is the only important person in Ada programming.
Premise 2: The reader wishes to learn from a package spec how to write
a call statement (essential knowledge: profile, contract, exceptions).
====
Conclusion: Anything that does not answer the reader's questions as stated
in premise 2 is in excess of what is needed, in general, and not beneficial.

> Why convention is an optimisation? <- "you still have unanswered question here"

I have answered this question twice. Specifically,
I have likened the two and pointed to the ground on which
the two aspects compare. I have *not* said that
convention *is* optimization, or vice versa. You may
have read this into my comparison of the reader's attitude
towards both, I think.

Again, if Ada.Strings.Fixed.Move has something with convention C,
then as the reader of Ada.Strings.Fixed I not only need
not care about that, thanks to Ada's separation of spec,
I don't want to be bothered with whatever mechanism
is used to make Move work. I want to be able to write Move,
and know what this does.

> Other things in your replacas while they are good in common I consider as
> demagogy here, sorry.

My impression is that you generalize a style that is useful
in your specific circumstances. I can't accept that as generally
useful and not as economically viable. Reason: I am the one who
always has to do the clean-up after a "pragmatic, cool" programmer
has left a company and I know the time it takes to make things
work in general, again.
Jobs: "Get this code to work in the new surroundings."
"Turn that clever hack into something that works when Xyz
changes", etc. You get allergic to things that should be
general, like a subprogram spec, but aren't because they
were written "pragmatically", and it takes time to sort
out which aspects are essential (influence the program's
output) and which aspects aren't.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue,  
07 Aug 2012 13:33:21 +0400:

>> The question was - WHY? And for what benefit?
>
> For the benefit of the reader who is concerned with
> what his program does when calling X, irrespective
> of anything to do with translation, or quality of
> the compiler, or distribution format of libraries.

You can place them just before a private part for the same doubtful  
benefit. So it is not an anwser to why to place in a private part?

Reading is context dependent, usually. I doubt that reading from several  
places in a file (adding such contexts) about one entity can be better  
readable than one context.

This means that a subject for reading is better readable if it is  
completed in one and well known its place (e.g. specification).

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 07.08.12 12:01, Simon Wright wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

>> When modelling, pragmatic hints seem all the more irrelevant.  When a
>> UML tool starts to dictate how package specifications should be made,
>> I start to worry a little.
> 
> If it's a good UML tool, you shouldn't need to look at the generated
> package specs that often (you will know what they look like from looking
> at the model). IMHO.

Is it good modelling, though, to add project specific aspects
to models, such as pragmatic hints that make sense only
for a specific compiler or with a specific way of translating
a library, or linking functions for specific debugging requirements?

If not, then the interfaces generated by the UML tool
should not have these aspects, either, I should think.
At least the reader interested in the model should be spared
the debugging specifics.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 07.08.12 15:45, Vasiliy Molostov wrote:
> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue, 07
> Aug 2012 13:33:21 +0400:
> 
>>> The question was - WHY? And for what benefit?
>>
>> For the benefit of the reader who is concerned with
>> what his program does when calling X, irrespective
>> of anything to do with translation, or quality of
>> the compiler, or distribution format of libraries.
> 
> You can place them just before a private part for the same doubtful benefit.
> So it is not an anwser to why to place in a private part?

The private part of a package is the place that human
readers can usually ignore completely, without loss.
This private part is meant for

(a) the implementer of the body, to harbor the private
    type's full view, etc.

(b) the compiler.

Only if I have reason to look at the private parts, uhum,
I do so, and I expect to see things there that usually are
none of my business.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue,  
07 Aug 2012 17:41:05 +0400:

> On 07.08.12 15:09, Vasiliy Molostov wrote:
>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме  
>> Tue, 07
>> Aug 2012 13:33:21 +0400:
>
> Premise 1: The reader is the only important person in Ada programming.
> Premise 2: The reader wishes to learn from a package spec how to write
> a call statement (essential knowledge: profile, contract, exceptions).
> ====
> Conclusion: Anything that does not answer the reader's questions as  
> stated
> in premise 2 is in excess of what is needed, in general, and not  
> beneficial.

I am the reader who wants to know from reading entity about all its  
properties, *while reading entity* . Since properties and a common name  
for them define entity.
pragmas placed along with such a entity gives me a way to obtain  
properties in one reading pass, e.g. as a part of entity.

pragmas being placed separately from entity breaks context and enforce  
reading two times more. In this case a reader have to ensure that a  
separated property is indeed the same one corresponding to what was  
specified before (a public subprogram spec), to match it exactly as  
possible, since additions in the public part with a new subprogram of the  
same name cause rewrite of other parts not related to that is added  
(should be concreted, since context in which first entity was defined  
becomes broken with separation).

> and it takes time to sort
> out which aspects are essential (influence the program's
> output) and which aspects aren't.

You are right here, and potentially there should be a way to setup these  
things as mandatory for the design and as a caller's appliance  
configuration.


-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Tue,  
07 Aug 2012 17:55:27 +0400:

> On 07.08.12 15:45, Vasiliy Molostov wrote:
>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме
> The private part of a package is the place that human
> readers can usually ignore completely, without loss.
> This private part is meant for
>
> (a) the implementer of the body, to harbor the private
>     type's full view, etc.

Indeed, a private part is for package extensions, e.g. child units. If  
there is a set of packages, organized in a tree, you alsways need to look  
at their private parts, if you plan to add your own child unit.



-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Simon Wright]

"Vasiliy Molostov" <molostoff@gmail.com> writes:

> Simon Wright <simon@pushface.org> писал(а) в своём письме Tue, 07 Aug
> 2012 14:01:27 +0400:

>> (to return/update the value of a component
>> declared in a private part)
>
> But as I understand a question was to setup inlining pragma in a
> private part for a subprogram which is specified in a public part.

I was agreeing that inlining may not improve speed. The example I was
giving was about "access subprograms", eg

   type T is private;
   ...
   function Get_C (From: T) return Integer; <=== an access subprogram
   ...
private
   ...
   type T is record
      C : Integer;
      ...
   end record;
   ...

   ...
   function Get_C (From: T) return Integer is
   begin
      return T.C;
   end Get_C;
   ...

which you would think would be a likely candidate for inlining.

Re: Should Inline be private in the private part of a package spec?

[Simon Wright]

"Vasiliy Molostov" <molostoff@gmail.com> writes:

> Simon Wright <simon@pushface.org> писал(а) в своём письме Tue, 07 Aug
> 2012 14:01:27 +0400:
>
>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>>
>>> On 06.08.12 23:01, Vasiliy Molostov wrote:
>>>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём
>>>> письме Mon, 06 Aug 2012 21:58:25 +0400:
>>>>
>>>>> When you c&p a subprogram's spec, when is that?
>>>>
>>>> When I use UML generator and wish to output subprogram specification
>>>> and its properties (e.g. inlining or convention) be printed in one
>>>> pass (line, stanza, sentence).
>>>
>>> When modelling, pragmatic hints seem all the more irrelevant.  When a
>>> UML tool starts to dictate how package specifications should be made,
>>> I start to worry a little.
>>
>> If it's a good UML tool, you shouldn't need to look at the generated
>> package specs that often (you will know what they look like from looking
>> at the model). IMHO.
>
> I doubt that any tool can be good enough, and use customized
> generator, and I found that changing generator can make a necessity to
> review what is generated, this greatly prevents UML tool from any
> dictate. I doubt that this process relate to modelling itself, btw.

You are right, I meant the combination of UML tool and code
generator. It would be unwise to change either without validating the
new combination.

Re: Should Inline be private in the private part of a package spec?

[Simon Wright]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:

> On 07.08.12 12:01, Simon Wright wrote:
>> Georg Bauhaus <rm.dash-bauhaus@futureapps.de> writes:
>
>>> When modelling, pragmatic hints seem all the more irrelevant.  When a
>>> UML tool starts to dictate how package specifications should be made,
>>> I start to worry a little.
>> 
>> If it's a good UML tool, you shouldn't need to look at the generated
>> package specs that often (you will know what they look like from looking
>> at the model). IMHO.
>
> Is it good modelling, though, to add project specific aspects
> to models, such as pragmatic hints that make sense only
> for a specific compiler or with a specific way of translating
> a library, or linking functions for specific debugging requirements?
>
> If not, then the interfaces generated by the UML tool
> should not have these aspects, either, I should think.
> At least the reader interested in the model should be spared
> the debugging specifics.

As I said to Vasily, I'm thinking of the combination of UML tool and
code generator.

Some vendors approach this by using all sorts of Ada-specific
stereotypes and tagged values, which I think is a mistake. In most
cases, you can use a standard markup to indicate language-specific
things; you might write an Ada generator so that if a class is marked
'active' instances will have associated tasks, whereas a C generator
would need to invoke pthreads.

This scheme doesn't always work; for Ada, you could mark a procedure
<<entry>>, but there may not be an obvious C/pthreads mapping.

I mentioned inlining access operations; we did the experiment by
changing the code generator so that for operations marked <<accessor>>
the corresponding "pragma Inline_Always" was output (next to the
subprogram declaration, sorry! but as I said it wasn't often necessary
to look at generated specs once you'd got used to the mappings).

http://coldframe.sourceforge.net/coldframe/

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Simon Wright <simon@pushface.org> писал(а) в своём письме Tue, 07 Aug 2012  
21:28:25 +0400:

> "Vasiliy Molostov" <molostoff@gmail.com> writes:
>
>> Simon Wright <simon@pushface.org> писал(а) в своём письме Tue, 07 Aug
>> 2012 14:01:27 +0400:
>
..
>
> which you would think would be a likely candidate for inlining.

Perhaps. Since it is an environment dependent, e.g. how internal data flow  
in a resulting image is organized by a compiler (e.g. stack and register  
alchemy) on a given hardware.

By using a word "pragma inline" we suppose, I think, "un-roll" expensive  
call with many parameters, referencing them directly to locals.

This can increase perfomance in loops where such a call is used, and is  
called many times. So, the more parameters we passed the more expensive  
becomes that call. As parameter count goes to be less as the expensiveness  
goes to be less, too.

I am not sure that the expense becomes zero with a parameter count equal  
to one, since it is a compiler (implementation) and architecture dependent  
thing, but indeed and doubtless, inlining in general can improve  
perfomance with this  call-in-a-loop stuff.

It is my opinion only.

> I was agreeing that inlining may not improve speed.

Yes, may not.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Monday, August 6, 2012 4:10:08 PM UTC-6, Georg Bauhaus wrote:
> On 06.08.12 23:52, Georg Bauhaus wrote:
> 
> >> Why you have decided that calling convention is an optinization?
> >
> > What the program does is not a matter of whether or not
> > some subprogram needs calling convention Ada or StdCall or
> > some such. Hence, from the perspective of the caller,
> > knowing the calling convention of an import is distraction
> > at best.
> 
> And, just like it is not normally important to know optimization
> issues when writing a call, it is not important to know
> the convention of an import when writing the call (of the
> Ada subprogram from the package spec). This is why I have
> likened optimization to calling conventions. They share the
> same degree of irrelevance from the caller's perspective.

No, that's not only wrong but _very_ wrong. Conventions are *vital* to a specification. Let us consider just one subprogram:
 Procedure Add(Object : In Out Our_Type; Value : In Integer);

Now with respect to this subprogram if "Pragma Convention( C, Add );" is applied then the parameters are pushed onto the stack Right-to-Left, and the calling-code is to handle cleanup. HOWEVER, if "Pragma Convention( Pascal, Add );" was applied the parameters would be pushed Left-to-Right and the function itself would handle the cleanup.

Even ignoring callee/caller cleanup there's a lot of difference here -- one's stack looks like this:
Object,
Value
The other's like this:
Value,
Object

That is, the convention drastically alters the interface, and is therefore properly placed into the specification (or possibly private section if you're providing an API layer).

Re: Should Inline be private in the private part of a package spec?

[Simon Wright]

Shark8 <onewingedshark@gmail.com> writes:

> On Monday, August 6, 2012 4:10:08 PM UTC-6, Georg Bauhaus wrote:

>> And, just like it is not normally important to know optimization
>> issues when writing a call, it is not important to know the
>> convention of an import when writing the call (of the Ada subprogram
>> from the package spec). This is why I have likened optimization to
>> calling conventions. They share the same degree of irrelevance from
>> the caller's perspective.
>
> No, that's not only wrong but _very_ wrong. Conventions are *vital* to
> a specification. Let us consider just one subprogram: Procedure
> Add(Object : In Out Our_Type; Value : In Integer);

Of course the Convention makes a difference to the calling sequence in
the object code (that's what it's _for_).

But why should the person who is writing the Ada code that makes the
call care one jot about the calling convention? In what way does it make
a difference to the code she writes?

After all, the calling sequence for a PowerPC target is going to be very
different to the calling sequence for an x86_64 target. You wouldn;t
expect the Ada (or even C) source code to reflect the difference!

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 08.08.12 03:48, Shark8 wrote:
>> it is not important to know
>> the convention of an import when writing the call (of the
>> Ada subprogram from the package spec).
>
> No, that's not only wrong but _very_ wrong. Conventions are *vital* to a specification.

Later, you said

> and is therefore properly placed into the specification (or possibly private section if you're providing an API layer).

Yes, these aspects could be written in the private part
of a package, which is what I had suggested. So that
compiler thingies and optimization issues and even compiler
specific pragmas would not litter the public part of a package spec.
They do that, IMHO, if you use aspect notation for pragma(tic) stuff.

> Let us consider just one subprogram:
>   Procedure Add(Object : In Out Our_Type; Value : In Integer);

Do the call statements change, though?

      Add (Some_Object, 42);

How do you, the programmer, have to change the above call
in order for the convention to be handled? You don't need to
change the way you write the call.

Calling conventions are for the compiler of high level languages,
for the most part. There are circumstances where the convention
becomes important, and the compiler should tell us.
Optimization can become important, too, and even then a compiler
like GNAT might warn about things that have been optimized away.
But both do not normally change the way a programmer writes
a correct call in source text. So, WRT writing call statements,
the interface of a subprogram can be understood without looking
at its calling convention, or considering implications for
speedier execution.

> That is, the convention drastically alters the interface,

Not at all. The calling convention alters the translation process,
and, possibly, its outcome. The convention does not alter the way
the programmer passes parameters in calls. The interface, in Ada,
would be a source text thing.

(And both Pascal compilers and C compilers might not even be
using a stack when translating the above call, for example, if both
parameters can be passed in registers, and the return address lives
in a special register, etc.. Or when the hardware does not even have
a stack, but still allows implementations of either language.)

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net...
> On 06.08.12 23:01, Vasiliy Molostov wrote:
...
> What the program does is not a matter of whether or not
> some subprogram needs calling convention Ada or StdCall or
> some such. Hence, from the perspective of the caller,
> knowing the calling convention of an import is distraction
> at best.

The convention can make the program legal or illegal: that's surely the 
definition of something that has to be in the specification. (For example, 
taking 'Access of a C convention subprogram and assigning it to an Ada 
convention access type is illegal for obvious reasons.)

Bob's point is that Inline doesn't make the program illegal per-se, so it is 
more of a gray area. But it does affect the compilation ordering, and IMHO, 
that needs to be visible information.

                                        Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:502040c0$0$9510$9b4e6d93@newsspool1.arcor-online.net...
> On 06.08.12 23:52, Georg Bauhaus wrote:
>
>>> Why you have decided that calling convention is an optinization?
>>
>> What the program does is not a matter of whether or not
>> some subprogram needs calling convention Ada or StdCall or
>> some such. Hence, from the perspective of the caller,
>> knowing the calling convention of an import is distraction
>> at best.
>
> And, just like it is not normally important to know optimization
> issues when writing a call,

That's only because most optimizations don't change the calling conventions.

>  it is not important to know
> the convention of an import when writing the call (of the
> Ada subprogram from the package spec).

This is definitely not true. The convention affects legality as well as code 
generation.

> This is why I have
> likened optimization to calling conventions. They share the
> same degree of irrelevance from the caller's perspective.

If optimizations changed the calling convention, then they would indeed have 
to be given in the specification. (Indeed, I would much prefer that that was 
the case; Janus/Ada simply does not do any optimizations for which the 
optimization level would matter, and this is the major reason. Otherwise, we 
would need compilation dependencies like Inline does, and the information 
would have to be in the specification.)

I detest the idea of separate project files like GPR; most of that 
information should have been in the Ada source (having it there makes the 
code more portable to other Ada implementations). The need for 
meta-languages always shows a lack in the original language.

                                              Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:5020d1fe$0$6566$9b4e6d93@newsspool3.arcor-online.net...
...
> Yes! For example, he should be able to see whether or not
> Move can be inlined.  But this case is special and, being a special case,
> should not clutter the specification of Move in Ada.Strings.Fixed!

I agree, but only because users should not be in the business of 
declaring/defining inlining. The compiler can figure that out much better 
than any declaration can.

I want implementation-independent hints about performance in package 
specifications, not ones describing specific techniques. That is, a 
declaration that calls on subprogram X ought to be compiled for the fastest 
possible performance or for the smallest possible space or for the best 
tradeoff possible. How that's accomplished should be left up to the 
implementation. Aspects like Inline and Pack get in the way of letting the 
compiler do the best possible job. (I don't believe that either of those 
even belong in the language -- which is one reason why Janus/Ada does almost 
nothing with either of them.)

                                         Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:5020e0e1$0$6570$9b4e6d93@newsspool3.arcor-online.net...
...
> Advances in compiler technology, or even varying the
> compilation processes, should not find a way into
> public parts of public packages made for re-use by others.
>
> package Reusable is
>
>   procedure Op (X : T)
>      with Inline => True,
>           Optimize => Time,
>        GNAT_Eliminate => Possibly,
>       Rational_Debug_Hook => Yes,
>        SofCheck_Inspectable => X;
>
> That's all relevant information in some hypothetical
> specific setup, but it is terribly at odds with re-usable Ada.
> These aspect are pragmatic, they are not relevant for re-use,
> they are extrinsic to Op's meaning.

I agree that most of this is junk, but not for the same reason. First, I 
don't think compiler-specific directives should even exist -- if they do, 
that shows a significant lack in the portable part of the language. (And 
yes, Ada has this sort of lack.) And I don't think they ought to be given 
anywhere, in any way (compiler "options" are just as harmful -- they're a 
perfect way to get vendor-lock-in.) Pragmatic considerations sometimes 
override good sense, but in that case, where or what they look like is 
already irrelevant -- you're already on the evil side of programming, 
nothing you can do will ever make these worthwhile. (Visible part, private 
part, project file, all are evil.)

The same goes for things like Inline and Pack (the latter as it is intended 
as "best efforts", and not as it is defined in Ada, which is seriously 
conflicted about what it means).

The *only* thing here should be an implementation-independent indicator of 
how this should be used (Optimization would work, but the existing choices 
don't quite give enough information. Probably a decent first cut, though.) 
And I'd argue that it has to be in the visible specification, as such a 
directive has to allow the creation of a compilation dependence (else most 
compilers could not inline).

                                          Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wccr4rkqed5.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
> If you like, show us an example of one of these "fails to link"
> cases.  Or don't bother -- it's really not that important.

Well, I don't want to waste more time on this, but I'm annoyed enough that I 
will.

First, we're talking about a compilation dependence here, not an elaboration 
or semantic dependence. That's not defined formally by the Ada 95 language, 
but of course it's necessary to any implementation. (I believe it was 
formally defined in Ada 83.)

Anyway, consider:

   package P is
      function F return Boolean with Inline;
   end P;

   package body P is
      function F return Boolean...
   end P;

   with P;
   procedure Q is
   begin
      if P.F then ...
   end Q;

Here, Q has a compilation dependence on the body of P. If the body of P is 
recompiled, then Q also has to be recompiled. If it is not, then the program 
must not be allowed to link. (That would be a violation of 10.1.4(5)).

Also note that 10.1.4(7/3) talks about "removing" compilation units that 
contain calls on inlined units when a new copy of the body is added (and 
"preexisting versions" of the body are removed). This has the effect of a 
compilation dependence.

(For Janus/Ada, we don't "remove" units, but we do refuse to bind units that 
contain references to old versions. I've always presumed that that was a 
correct implementation of these two rules.)

IMHO, compilation dependences should be given in the visible part of the 
package (preferable in the context clause), so that the 1% of Ada 
programmers that compile files by hand can accurately find the dependences. 
Requiring the use of implementation-defined tools like GNAT's Gnatmake or 
Janus/Ada's COrder is obnoxious. Thus "Inline" needs to be given in the 
visible spec.

If 10.1.4(7/3) didn't exist, then Inline would not need to be given in 
visible spec. But as I noted elsewhere, I don't think Inline should be given 
anywhere -- compilers can figure out when to Inline better than any human 
can. Hints about the amount of space expansion allowed for the entire 
program and the relative importance of particular subprograms would be much 
more valuable.

                                                   Randy.

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Thursday, August 9, 2012 4:18:40 PM UTC-6, Randy Brukardt wrote:
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
> 
> If 10.1.4(7/3) didn't exist, then Inline would not need to be given in 
> visible spec. But as I noted elsewhere, I don't think Inline should be given 
> anywhere -- compilers can figure out when to Inline better than any human 
> can. Hints about the amount of space expansion allowed for the entire 
> program and the relative importance of particular subprograms would be much 
> more valuable.

Well, isn't that the reason that Pragma Inline allows the compiler to inline the subprogram, rather than being a compiler switch _requiring_ the subprogram to be inlined?

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:50211aed$0$6571$9b4e6d93@newsspool3.arcor-online.net...
...
> Premise 1: The reader is the only important person in Ada programming.
> Premise 2: The reader wishes to learn from a package spec how to write
> a call statement (essential knowledge: profile, contract, exceptions).

Premise 2, as you've stated it here, is clearly wrong. It would be much 
better stated as

The reader wishes to learn from a package spec whatever they need to know 
about using the package.

That might be how to write a call, but it also might be how to write an 
object declaration, a type extension, an access type declaration, or one of 
many other possibilities.

They also might want to know how to compile the program successfully, either 
because they want to compile the program by hand, or because they're some 
sort of tool. (Most of the Janus/Ada tools only read the context clause and 
visible part of packages; we don't want any privacy leakage and we 
definitely wanted to avoid reading large specifications.)

Point is, that it's pretty hard to tell want a reader wants. As Vasilly 
said, it's very annoying to have to look all over the place to find the 
information you need. Moreover, having a bunch of aspects at the end of a 
subprogram declaration has almost no effect on its readability, because you 
don't need to read past the "with" unless you care about the aspects. (This 
is just like not reading the private part if you don't need to know 
something about that.) So I see no advantage to the style of putting things 
in the private part, and there are lots of disadvantages (hidden 
dependencies, hard to find the information when it is needed, hard to tell 
when it is missing [because omissions are much harder to find than 
commissions], and much more likely to run into freezing problems).

                                 Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Simon Wright" <simon@pushface.org> wrote in message 
news:m2hasf10nc.fsf@nidhoggr.home...
...
> Completely agree. We found (on powerpc-wrs-vxworks) that globally
> inlining access subprograms (to return/update the value of a component
> declared in a private part) increased the size and slowed the code. No
> metrics, sorry.

OT: I usually call those sorts of subprograms "accessors" in order to reduce 
confusion with "access types" in Ada. I had to read your message several 
times to figure out what you meant.

                             Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Shark8" <onewingedshark@gmail.com> wrote in message 
news:613764f5-0216-4271-9278-70290198d71d@googlegroups.com...
> On Thursday, August 9, 2012 4:18:40 PM UTC-6, Randy Brukardt wrote:
>> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
>>
>> If 10.1.4(7/3) didn't exist, then Inline would not need to be given in
>> visible spec. But as I noted elsewhere, I don't think Inline should be 
>> given
>> anywhere -- compilers can figure out when to Inline better than any human
>> can. Hints about the amount of space expansion allowed for the entire
>> program and the relative importance of particular subprograms would be 
>> much
>> more valuable.
>
> Well, isn't that the reason that Pragma Inline allows the compiler to 
> inline the
> subprogram, rather than being a compiler switch _requiring_ the subprogram 
> to be inlined?

Sure. But nothing prevents a compiler from inlining any subprogram it wants. 
And if it can, it ought to inline every subprogram that makes sense.

So the only real advantages of Inline are
(1) Adding a compilation dependence, which makes it easier to implement on 
most compilers;
(2) Providing a rather non-specific hint that it might be a good idea to 
inline this subprogram.

I'd rather have a more specific hint, and let the compiler decide how best 
to implement it. (And get rid of the compiler dependence -- nothing good 
comes out of extra dependences.) In particular, some subprogram might be 
best partially inlined (that is, substituting some but not all parameters in 
a duplicate of the subprogram). For example, imagine New_Line, where the 
second parameter is rarely used. And on some machines, a call is going to be 
no more expensive than the inlined code (in which case the call is preferred 
because it could decrease cache pressure). And so on...

                                         Randy.

Re: Should Inline be private in the private part of a package spec?

[Britt]

On Thursday, August 9, 2012 5:39:32 PM UTC-4, Randy Brukardt wrote:
 
> 
> I detest the idea of separate project files like GPR; most of that 
> information should have been in the Ada source (having it there makes the 
> code more portable to other Ada implementations). The need for 
> meta-languages always shows a lack in the original language.
> 

I think GPR files are fabulous. I see them as a well designed framework for managing the development and build process. Almost all of the information that goes in GPR files is about project structure (e.g. file locations), settings for GNAT's ASIS-based tools, and some IDE options. I don't really see any overlap with information I would want to put in source code. Other Ada implementations would benefit from something similar.

- Britt

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Thursday, August 9, 2012 7:49:07 PM UTC-6, Britt wrote:
> On Thursday, August 9, 2012 5:39:32 PM UTC-4, Randy Brukardt wrote:
> 
> > 
> > I detest the idea of separate project files like GPR; most of that 
> > information should have been in the Ada source (having it there makes the 
> > code more portable to other Ada implementations). The need for 
> > meta-languages always shows a lack in the original language.
> 
> I think GPR files are fabulous. I see them as a well designed framework for managing the development and build process. Almost all of the information that goes in GPR files is about project structure (e.g. file locations), settings for GNAT's ASIS-based tools, and some IDE options. I don't really see any overlap with information I would want to put in source code. Other Ada implementations would benefit from something similar.

I have mixed feelings about gpr-files.
It would be interesting to have a DB-based system (or somesuch) where the source isn't stored as a simple text-file; though perhaps that would be a lot of work for little payoff. (The library-system and ALI-files could be handled in this manner though.)

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug 2012  
07:10:57 +0400:

> On Thursday, August 9, 2012 7:49:07 PM UTC-6, Britt wrote:
>> On Thursday, August 9, 2012 5:39:32 PM UTC-4, Randy Brukardt wrote:
>>
>> >

>
> I have mixed feelings about gpr-files.
> It would be interesting to have a DB-based system (or somesuch) where  
> the source isn't stored as a simple text-file; though perhaps that would  
> be a lot of work for little payoff. (The library-system and ALI-files  
> could be handled in this manner though.)

I dont think that placement sources in a db is a portable way, since text  
is still most
widely used and simple format on all host systems.

But the placement by the compiler of all intermediate files (compilation  
result) such as ali+obj into one library file directly would be a great  
step forward, since most ada devlibs are used to be built into library  
files anyway (whose are db already). This might increare compilation times  
drastically due to less overhead on omitting os calls like readdir() and  
glob() things, which is important on large amount of source and ali/object  
paired files.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Thu, 9 Aug 2012 20:10:57 -0700 (PDT), Shark8 wrote:

> I have mixed feelings about gpr-files.

GPR has its issues but it is a major step forward comparing to other
techniques.

> It would be interesting to have a DB-based system (or somesuch) where the
> source isn't stored as a simple text-file; though perhaps that would be a
> lot of work for little payoff. (The library-system and ALI-files could be
> handled in this manner though.)

This is a different issue. ClearCase for example keeps sources in a DB, yet
interfaced as plain text files.

However the point is valid. The OS should be natively OO and the Ada source
should be an object implementing various interfaces additionally to the
"text buffer" interface. In some different world, but this one dominated by
living fossils...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 09.08.12 23:39, Randy Brukardt wrote:

>>   it is not important to know
>> the convention of an import when writing the call (of the
>> Ada subprogram from the package spec).
>
> This is definitely not true. The convention affects legality as well as code
> generation.

Just saying that legality may or may not appear on the programmer's radar,
depending on whether he or she declares a subprogram pointer type, say.
The compiler's error message might be surprising otherwise, the one about
the subprogram pointer type needing the same convention as the subprogram.

Another impressive case,

   function New_T (X : Integer; this : T_Ptr := null) return T_Ptr
      with Convention => Java_Constructor;

Thinking of SofCheck's (now AdaCore's) or AdaCore's (still AdaCore's)
Ada->JVM translators. The convention here really makes all client
programmers aware that everything at or near New_T needs special
attention. "All" is slightly more than 1% wishing to compile without
the help of a computer program ;-)

Elsewhere:
> The*only*  thing here should be an implementation-independent indicator of
> how this should be used

Much better wording than what I had. I'd add to your assessment of the
use of Inline that if it should be present at all, it should give
control to the user, not permission to the compiler; as it is now,
Inline cannot be used to prevent inlining, so the programmer cannot
control inlining with the help of Inline.

Re: Should Inline be private in the private part of a package spec?

[Simon Wright]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "Simon Wright" <simon@pushface.org> wrote in message 
> news:m2hasf10nc.fsf@nidhoggr.home...
> ...
>> Completely agree. We found (on powerpc-wrs-vxworks) that globally
>> inlining access subprograms (to return/update the value of a component
>> declared in a private part) increased the size and slowed the code. No
>> metrics, sorry.
>
> OT: I usually call those sorts of subprograms "accessors" in order to reduce 
> confusion with "access types" in Ada. I had to read your message several 
> times to figure out what you meant.

As I think I may have said, we marked these subprograms <<accessor>> in
the UML, which goes to prove your point. Thanks.

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Friday, August 10, 2012 12:00:26 AM UTC-6, Vasiliy Molostov wrote:
> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug 2012  
> 
> > I have mixed feelings about gpr-files.
> > It would be interesting to have a DB-based system (or somesuch) where  
> > the source isn't stored as a simple text-file; though perhaps that would  
> > be a lot of work for little payoff. (The library-system and ALI-files  
> > could be handled in this manner though.)
> 
> I dont think that placement sources in a db is a portable way, since text  
> is still most
> widely used and simple format on all host systems.

That's actually pretty irrelevant; given such a system it should be near-trivial to implement text-file import/export... even iterating over the project/directory.

> But the placement by the compiler of all intermediate files (compilation  
> result) such as ali+obj into one library file directly would be a great  
> step forward, since most ada devlibs are used to be built into library  
> files anyway (whose are db already). This might increare compilation times  
> drastically due to less overhead on omitting os calls like readdir() and  
> glob() things, which is important on large amount of source and ali/object  
> paired files.

Um, don't you mean decrease compilation time?

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Friday, August 10, 2012 1:37:04 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> However the point is valid. The OS should be natively OO and the Ada source
> should be an object implementing various interfaces additionally to the
> "text buffer" interface. In some different world, but this one dominated by
> living fossils...

Indeed so. In fact, I think that's just scraping the surface of how an OS should handle files. It should have files [strongly-]typed, perhaps with a validated flag to indicate that that type is known to be true (perhaps the type indicator implemented as a signed 64-bit integer, which would have a magnitude indicating the file-type; negative values indicating non-validated files. [0 would be a straight-up binary file, as all files would be binary it makes no sense for validation thereon; the extra-negative value, assuming 2's complement, could indicate truly unknown]). Furthermore, each file-type should have a corresponding object which knows how to read, write & validate itself.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Fri, 10 Aug 2012 09:45:03 -0700 (PDT), Shark8 wrote:

> On Friday, August 10, 2012 1:37:04 AM UTC-6, Dmitry A. Kazakov wrote:
>> 
>> However the point is valid. The OS should be natively OO and the Ada source
>> should be an object implementing various interfaces additionally to the
>> "text buffer" interface. In some different world, but this one dominated by
>> living fossils...
> 
> Indeed so. In fact, I think that's just scraping the surface of how an OS
> should handle files. It should have files [strongly-]typed, perhaps with a
> validated flag to indicate that that type is known to be true (perhaps the
> type indicator implemented as a signed 64-bit integer, which would have a
> magnitude indicating the file-type; negative values indicating
> non-validated files. [0 would be a straight-up binary file, as all files
> would be binary it makes no sense for validation thereon; the
> extra-negative value, assuming 2's complement, could indicate truly
> unknown]). Furthermore, each file-type should have a corresponding object
> which knows how to read, write & validate itself.

No files, only persistent objects. Instead of file type you would have a
type tag, kept memory protected. The operations would be protected too, so
that you could not call a wrong operation on the object even if you knew
its entry point address and used any fancy unchecked conversion stuff.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Simon Wright]

Shark8 <onewingedshark@gmail.com> writes:

> I have mixed feelings about gpr-files.
> It would be interesting to have a DB-based system (or somesuch) where
> the source isn't stored as a simple text-file; though perhaps that
> would be a lot of work for little payoff. (The library-system and
> ALI-files could be handled in this manner though.)

Personally, I can't see any way in which that would be interesting or
beneficial ...

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Friday, August 10, 2012 11:03:08 AM UTC-6, Dmitry A. Kazakov wrote:
> On Fri, 10 Aug 2012 09:45:03 -0700 (PDT), Shark8 wrote:
> 
> 
> 
> > On Friday, August 10, 2012 1:37:04 AM UTC-6, Dmitry A. Kazakov wrote:
> 
> >> 
> 
> >> However the point is valid. The OS should be natively OO and the Ada source
> 
> >> should be an object implementing various interfaces additionally to the
> 
> >> "text buffer" interface. In some different world, but this one dominated by
> 
> >> living fossils...
> 
> > 
> 
> > Indeed so. In fact, I think that's just scraping the surface of how an OS
> 
> > should handle files. It should have files [strongly-]typed, perhaps with a
> 
> > validated flag to indicate that that type is known to be true (perhaps the
> 
> > type indicator implemented as a signed 64-bit integer, which would have a
> 
> > magnitude indicating the file-type; negative values indicating
> 
> > non-validated files. [0 would be a straight-up binary file, as all files
> 
> > would be binary it makes no sense for validation thereon; the
> 
> > extra-negative value, assuming 2's complement, could indicate truly
> 
> > unknown]). Furthermore, each file-type should have a corresponding object
> 
> > which knows how to read, write & validate itself.
> 
> 
> 
> No files, only persistent objects. Instead of file type you would have a
> 
> type tag, kept memory protected. The operations would be protected too, so
> 
> that you could not call a wrong operation on the object even if you knew
> 
> its entry point address and used any fancy unchecked conversion stuff.
> 
> 
> 
> -- 
> 
> Regards,
> 
> Dmitry A. Kazakov
> 
> http://www.dmitry-kazakov.de

Files *are* persistent objects... indeed, they are persistent across power-on/power-off cycles, which makes them even more persistent than anything else in the system (save the hardware).

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Fri, 10 Aug 2012 14:35:28 -0700 (PDT), Shark8 wrote:

> Files *are* persistent objects... indeed, they are persistent across
> power-on/power-off cycles, which makes them even more persistent than
> anything else in the system (save the hardware).

1. Files are weakly typed objects. One can "reinterpret" a file as one can
reinterpret anything in C.

2. The operations defined on files do not reflect the semantics of the
contents but the semantics of the file system, e.g. reading, writing. It is
low-level stuff. Compare this with Integer is a higher-level language. You
don't read integers. You would do this in an assemble language, loading
registers, storing them into memory etc. When I say "object" I mean an
object of some ADT, rather that objects found in Assemble language.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug 2012  
20:34:24 +0400:

> On Friday, August 10, 2012 12:00:26 AM UTC-6, Vasiliy Molostov wrote:
>> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug  
>> 2012
>>
>> > I have mixed feelings about gpr-files.
>> > It would be interesting to have a DB-based system (or somesuch) where
>> > the source isn't stored as a simple text-file; though perhaps that  
>> would
>> > be a lot of work for little payoff. (The library-system and ALI-files
>> > could be handled in this manner though.)
>>
>> I dont think that placement sources in a db is a portable way, since  
>> text
>> is still most
>> widely used and simple format on all host systems.
>
> That's actually pretty irrelevant; given such a system it should be  
> near-trivial to implement text-file import/export... even iterating over  
> the project/directory.

this needs a presence of such a tool and additional database access tools.
While currently you still need any text editor.
So the cost of this solution is higher with less flexibility, you will be  
obliged
to accommodate interchange format with client or supplier of such a  
database to import/export it properly,
mostly about text import/export properties.

You can try to use tar/tgz files as a database and extend it with desired  
features,
and as I see it you will get the same as jar files in java world. Another  
good example is a debian source packages -
very inconvenient for a development (but convenient for distribution), and  
even requires a special role for that - a package maintainer.

>> But the placement by the compiler of all intermediate files (compilation
>> result) such as ali+obj into one library file directly would be a great
>> step forward, since most ada devlibs are used to be built into library
>> files anyway (whose are db already). This might increare compilation  
>> times
>> drastically due to less overhead on omitting os calls like readdir() and
>> glob() things, which is important on large amount of source and  
>> ali/object
>> paired files.
>
> Um, don't you mean decrease compilation time?

yep, decrease. auto-thesaurus failed, not me. :)


-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Britt" <britt.snodgrass@gmail.com> wrote in message 
news:50677fa2-7f82-4ccc-8c56-161bf67fefe1@googlegroups.com...
On Thursday, August 9, 2012 5:39:32 PM UTC-4, Randy Brukardt wrote:

>> I detest the idea of separate project files like GPR; most of that
>> information should have been in the Ada source (having it there makes the
>> code more portable to other Ada implementations). The need for
>> meta-languages always shows a lack in the original language.

>I think GPR files are fabulous. I see them as a well designed framework for 
>managing
> the development and build process. Almost all of the information that goes 
> in GPR files
> is about project structure (e.g. file locations), settings for GNAT's 
> ASIS-based tools,
> and some IDE options. I don't really see any overlap with information I 
> would want
> to put in source code.

This is "information" that you shouldn't have to put anywhere at all - it's 
just cruft that is needed because of poor mappings to the underlying system. 
Better systems in the future won't use most of this stuff, it will alll 
happen automatically.

I've recently talked to several customers that don't use any sort of 
sophisticated project management at all: they simply make a new directory 
and populate it with the contents of version control when anything needs to 
change. (One of these customers was managing several thousand files this 
way). Then, they just point the build tools at it and go -- no complex 
project files needed (or wanted). They thought that complex project 
organizations just added complications on modern hardware, and I tend to 
agree. (The recompilation time they would save with shared files is probably 
less than the time that they would spend on managing the projects.)

YMMV, of course, but I think "one-button builds" from raw (and portable) 
source code is the ideal way to go. I'm now looking at ways to make that 
easier with Janus/Ada (one obvious way is to eliminate the need for any 
special naming conventions for Ada source code).

                                               Randy.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Randy Brukardt <randy@rrsoftware.com> писал(а) в своём письме Sat, 11 Aug  
2012 04:46:59 +0400:

> YMMV, of course, but I think "one-button builds" from raw (and portable)
> source code is the ideal way to go. I'm now looking at ways to make that
> easier with Janus/Ada (one obvious way is to eliminate the need for any
> special naming conventions for Ada source code).

Does it means that there would be a something like intermediate database  
(e.g. index)?

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Friday, August 10, 2012 4:10:12 PM UTC-6, Dmitry A. Kazakov wrote:
> On Fri, 10 Aug 2012 14:35:28 -0700 (PDT), Shark8 wrote:
> 
> > Files *are* persistent objects... indeed, they are persistent across
> > power-on/power-off cycles, which makes them even more persistent than
> > anything else in the system (save the hardware).
> 
> 1. Files are weakly typed objects. One can "reinterpret" a file as one can
> reinterpret anything in C.

Not entirely correct; most of that has to do with the OS's own design. IIRC the Apple computer had a typed file-system that made the assumption that a file's type was associated w/ a particular program.

> 2. The operations defined on files do not reflect the semantics of the
> contents but the semantics of the file system, e.g. reading, writing. It is
> low-level stuff. Compare this with Integer is a higher-level language. You
> don't read integers. You would do this in an assemble language, loading
> registers, storing them into memory etc. When I say "object" I mean an
> object of some ADT, rather that objects found in Assemble language.

They should have those high-level operations, but I believe they should also have a base/common interface; that is, the OS should also be able to operate on file_type'class objects w/o worrying if it's a MIDI file or an Ada file.

Indeed there might be an entire hierarchy of classes such that mp3, midi, and avi files all have a Play method being that they all belong to the multimedia class, and midi and mp3 even more-tightly being audio-files.

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Friday, August 10, 2012 4:37:33 PM UTC-6, Vasiliy Molostov wrote:
> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug 2012 20:34:24 +0400:
> 
> 
> > On Friday, August 10, 2012 12:00:26 AM UTC-6, Vasiliy Molostov wrote:
> >> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug  
> >> 2012
> >>
> >> > I have mixed feelings about gpr-files.
> >> > It would be interesting to have a DB-based system (or somesuch) where
> >> > the source isn't stored as a simple text-file; though perhaps that  
> >> would
> >> > be a lot of work for little payoff. (The library-system and ALI-files
> >> > could be handled in this manner though.)
> >>
> >> I dont think that placement sources in a db is a portable way, since  
> >> text
> >> is still most
> >> widely used and simple format on all host systems.
> >
> > That's actually pretty irrelevant; given such a system it should be  
> > near-trivial to implement text-file import/export... even iterating over  
> > the project/directory.
> 
> this needs a presence of such a tool and additional database access tools.

Not really, the database access tools would already be there; they would have to be if you were compiling with the system.

> While currently you still need any text editor.

Um, I don't really see the relevance of mentioning a text editor here... so, why?

> So the cost of this solution is higher with less flexibility, you will be  
> obliged
> to accommodate interchange format with client or supplier of such a  
> database to import/export it properly,
> mostly about text import/export properties.

Again, not really; the same way the system would say "we need these objects" is the same way to determine what to export.

> 
> You can try to use tar/tgz files as a database and extend it with desired  
> features,
> and as I see it you will get the same as jar files in java world.

Ew. And that would likely be a horrid idea, updating an object/ALI/source would essentially consist of:
1 - Create a temporary, but properly named file.
2 - Open the archive, adding (w/ replacement/overwrite) the file.
{Incidentally this also would require running the file through the archive's compression.}
3 - Delete the temp-file.

For EVERY change you enact.

> Another  
> good example is a debian source packages -
> very inconvenient for a development (but convenient for distribution), and  
> even requires a special role for that - a package maintainer.

I know nothing about Debian in particular; but I do hate Linux (and Unix) in general. In fact, I think a lot of the blame of "all source-files *must* be plain-text" stems from them. {There's really no reason that source text should be stored as a plain-text for general purpose/use... indeed if it were stored as a structured-file an editor could prevent/warn storing the text if it had syntax errors.}

Yes, plain-text editors are everywhere.... but there's a lot more

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Sat, 11 Aug 2012  
07:44:09 +0400:

>> this needs a presence of such a tool and additional database access  
>> tools.
>
> Not really, the database access tools would already be there; they would  
> have to be if you were compiling with the system.

To be already there these should be presented before.

>> While currently you still need any text editor.
>
> Um, I don't really see the relevance of mentioning a text editor here...  
> so, why?

Opposite to db tool is the editor, in use (any). You operate sources with  
it for now.

>> So the cost of this solution is higher with less flexibility, you will  
>> be
>> obliged
>> to accommodate interchange format with client or supplier of such a
>> database to import/export it properly,
>> mostly about text import/export properties.
>
> Again, not really; the same way the system would say "we need these  
> objects" is the same way to determine what to export.

What these objects? Everything should be defined in some manner before use.

> 2 - Open the archive, adding (w/ replacement/overwrite) the file.
> {Incidentally this also would require running the file through the  
> archive's compression.}

tar has some support for archive format auto-recognition, also it has  
already an update operation.

> 3 - Delete the temp-file.
>
> For EVERY change you enact.

You have offered it.

> I know nothing about Debian in particular; but I do hate Linux (and  
> Unix) in general. In fact, I think a lot of the blame of "all  
> source-files *must* be plain-text" stems from them.

Ye. Hating is funny, surely? I can recommend write tar in Ada to make it  
more portable
as a good starting point for a db backend storage.

> {There's really no reason that source text should be stored as a  
> plain-text for general purpose/use... indeed if it were stored as a  
> structured-file an editor could prevent/warn storing the text if it had  
> syntax errors.}

Try searching for APL programming terminals, a good intro to visual  
automated programming.

> Yes, plain-text editors are everywhere.... but there's a lot more

Yep. I like my bike, for example.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug 2012  
20:45:03 +0400:


> Indeed so. In fact, I think that's just scraping the surface of how an  
> OS should handle files. It should have files [strongly-]typed, perhaps  
> with a validated flag to indicate that that type is known to be true  
> (perhaps the type indicator implemented as a signed 64-bit integer,  
> which would have a magnitude indicating the file-type; negative values  
> indicating non-validated files. [0 would be a straight-up binary file,  
> as all files would be binary it makes no sense for validation thereon;  
> the extra-negative value, assuming 2's complement, could indicate truly  
> unknown]). Furthermore, each file-type should have a corresponding  
> object which knows how to read, write & validate itself.

Perhaps you might know that ada.direct_io is a carbon copy of record  
oriented files implemented in vms,
and a rest (historical sublime) of that file system is currently named as  
ntfs?

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Friday, August 10, 2012 10:48:20 PM UTC-6, Vasiliy Molostov wrote:
> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Fri, 10 Aug 2012  
> 20:45:03 +0400:
> 
> 
> > Indeed so. In fact, I think that's just scraping the surface of how an  
> > OS should handle files. It should have files [strongly-]typed, perhaps  
> > with a validated flag to indicate that that type is known to be true  
> > (perhaps the type indicator implemented as a signed 64-bit integer,  
> > which would have a magnitude indicating the file-type; negative values  
> > indicating non-validated files. [0 would be a straight-up binary file,  
> > as all files would be binary it makes no sense for validation thereon;  
> > the extra-negative value, assuming 2's complement, could indicate truly  
> > unknown]). Furthermore, each file-type should have a corresponding  
> > object which knows how to read, write & validate itself.
> 
> Perhaps you might know that ada.direct_io is a carbon copy of record  
> oriented files implemented in vms,
> and a rest (historical sublime) of that file system is currently named as  
> ntfs?

I didn't know that about Direct_IO; that's really interesting.
Is NTFS really that much of a decedent of VMS's file-system? I was under the impression that VMS's had quite a few more features than NTFS, though it's been a long while since I read-up on FSes.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Fri, 10 Aug 2012 20:27:27 -0700 (PDT), Shark8 wrote:

> On Friday, August 10, 2012 4:10:12 PM UTC-6, Dmitry A. Kazakov wrote:
>> On Fri, 10 Aug 2012 14:35:28 -0700 (PDT), Shark8 wrote:
>> 
>>> Files *are* persistent objects... indeed, they are persistent across
>>> power-on/power-off cycles, which makes them even more persistent than
>>> anything else in the system (save the hardware).
>> 
>> 1. Files are weakly typed objects. One can "reinterpret" a file as one can
>> reinterpret anything in C.
> 
> Not entirely correct; most of that has to do with the OS's own design.
> IIRC the Apple computer had a typed file-system that made the assumption
> that a file's type was associated w/ a particular program.

C makes assumption too. That does not make typing strong.

>> 2. The operations defined on files do not reflect the semantics of the
>> contents but the semantics of the file system, e.g. reading, writing. It is
>> low-level stuff. Compare this with Integer is a higher-level language. You
>> don't read integers. You would do this in an assemble language, loading
>> registers, storing them into memory etc. When I say "object" I mean an
>> object of some ADT, rather that objects found in Assemble language.
> 
> They should have those high-level operations, but I believe they should
> also have a base/common interface; that is, the OS should also be able to
> operate on file_type'class objects w/o worrying if it's a MIDI file or an
> Ada file.

Operate = applying operations. Interface = set of operations.

You cannot do anything without having an operation. The point is about weak
vs. strong typing and ADT POV.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Robert A Duff]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> Well, I don't want to waste more time on this, but I'm annoyed enough that I 
> will.

Umm, ... thanks.  I guess.  I don't know why you would be annoyed over
a technical disagreement.  Or a technical misunderstanding, if that's
what it is.

> First, we're talking about a compilation dependence here, not an elaboration 
> or semantic dependence. That's not defined formally by the Ada 95 language, 

Or, to put it in language-lawyer-ese:  There's no such thing as
"compilation dependence" in Ada.  ;-)  This is a concept that some
compilers define, and they don't all necessarily define it the
same way.  You shouldn't be surprised that I misunderstood
when you use "dependence" in a nonstandard way in a language-lawyer
discussion!

> but of course it's necessary to any implementation. (I believe it was 
> formally defined in Ada 83.)

I don't remember about Ada 83 -- you're probably right about that.

> Anyway, consider:
>
>    package P is
>       function F return Boolean with Inline;
>    end P;
>
>    package body P is
>       function F return Boolean...
>    end P;
>
>    with P;
>    procedure Q is
>    begin
>       if P.F then ...
>    end Q;
>
> Here, Q has a compilation dependence on the body of P. If the body of P is 
> recompiled, then Q also has to be recompiled. If it is not, then the program 
> must not be allowed to link. (That would be a violation of 10.1.4(5)).

Sure, but I don't see any conformance issue, here.  The compiler may
require that you recompile Q "by hand" before you can run the program.
Or it can do it automatically.  Or it could have a separate tool
(like gnatmake) that does it automatically.  The above is a legal
program, and a conforming implementation must provide SOME way
to run it.  Yours does.  GNAT does.

(Ada doesn't have a concept of "link", either -- the issue is whether
you can run the program.)

> Also note that 10.1.4(7/3) talks about "removing" compilation units that 
> contain calls on inlined units when a new copy of the body is added (and 
> "preexisting versions" of the body are removed). This has the effect of a 
> compilation dependence.
>
> (For Janus/Ada, we don't "remove" units, but we do refuse to bind units that 
> contain references to old versions. I've always presumed that that was a 
> correct implementation of these two rules.)

Yes, I believe it is correct.  You are "removing" it in the sense that
the RM means (even though some data might still be there on the disk).

> IMHO, compilation dependences should be given in the visible part of the 
> package (preferable in the context clause), ...

OK, now I see what you're getting at.

Well, you can't put pragmas Inline in the context clause!
You can put them in the visible part, and apparently that's
what you want to require.

However, that doesn't quite achieve your stated goal.  GNAT has a similar
concept of compilation dependences, but it also includes generics:
if Q instantiates something in P, then if P's body is recompiled,
Q needs to be recompiled (and gnatmake will do that automatically).

The problem is that the pragma Inline above doesn't necessarily
imply a compilation dependence -- it does only if Q calls the inlined
thing, and only if inlining is turned on, and only if the compiler
is able to do the inlining.  At least, that's the way GNAT works.

Similarly, for generics, a compilation dependence is only
necessary for things that actually instantiate something.
(And in your compiler, you never "inline" (i.e. macro-expand)
generics, so there's no dependence.)

>...so that the 1% of Ada 
> programmers that compile files by hand can accurately find the dependences. 

They will recompile things unnecessarily.

> Requiring the use of implementation-defined tools like GNAT's Gnatmake or 
> Janus/Ada's COrder is obnoxious. Thus "Inline" needs to be given in the 
> visible spec.

Shrug.  How could failing to satisfy the 1% that use stone axes
be "obnoxious".  At worst, it's "mildly annoying to a small minority".

I wouldn't want to use an Ada compiler that doesn't do automatic
recompilation.  In fact, GNAT itself is built without using gnatmake,
because it's part of gcc, and gcc uses primitive stone-ax-like tools
('make', ...).  It's a nightmare.

> If 10.1.4(7/3) didn't exist, then Inline would not need to be given in 
> visible spec.

The last sentence of that paragraph is there to avoid requiring
Ada 83 compilers to change their ways.

>... But as I noted elsewhere, I don't think Inline should be given 
> anywhere -- compilers can figure out when to Inline better than any human 
> can.

In most cases, yes.  I still think there's a place for compiler hints,
such as pragma Inline.

>... Hints about the amount of space expansion allowed for the entire 
> program and the relative importance of particular subprograms would be much 
> more valuable.

And profile-guided optimization.  And JIT compilation.

- Bob

Re: Should Inline be private in the private part of a package spec?

[Jacob Sparre Andersen]

Shark8 wrote:

> I know nothing about Debian in particular; but I do hate Linux (and
> Unix) in general. In fact, I think a lot of the blame of "all
> source-files *must* be plain-text" stems from them. {There's really no
> reason that source text should be stored as a plain-text for general
> purpose/use... indeed if it were stored as a structured-file an editor
> could prevent/warn storing the text if it had syntax errors.}
>
> Yes, plain-text editors are everywhere.... but there's a lot more

It is definitely a bit disappointing that (practically) no programming
language goes beyond a plain text source format.  But as an exercise;
try to specify the (equivalent of) Ada in terms of a structured file
format rather than a plain text format.  (And remember to make sure the
format should be portable to "any" operating system/architecture.)
Exercise two is to adjust your Ada equivalent language to make use of
the structured file format beyond ensuring that stored source is
syntactically correct.

Poul-Henning Kamp has written an essay (a "rant"?) about this problem in
ACM Queue: <http://queue.acm.org/detail.cfm?id=1871406>

Greetings,

Jacob
-- 
WTFM: Write the Fine Manual

Project files (Was: Should Inline be private in the private part of a package spec?)

[Jacob Sparre Andersen]

Randy Brukardt wrote:

> (The recompilation time they would save with shared files is probably
> less than the time that they would spend on managing the projects.)

We don't use project files to save compilation time.  We do it to:

 a) reuse shared libraries

 b) direct the compiler at the proper target-specific package bodies

> YMMV, of course, but I think "one-button builds" from raw (and
> portable) source code is the ideal way to go.

Agreed.

> I'm now looking at ways to make that easier with Janus/Ada (one
> obvious way is to eliminate the need for any special naming
> conventions for Ada source code).

How would you handle multiple available bodies for the same package?  (I
imagine it would turn it into at least a "two-button build".)

Greetings,

Jacob
-- 
"Don't get me wrong, perl is an OK operating system, but it
 lacks a lightweight scripting language."

Re: Project files (Was: Should Inline be private in the private part of a package spec?)

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message 
news:87zk5zngnc.fsf_-_@adaheads.sparre-andersen.dk...
> Randy Brukardt wrote:
>
>> (The recompilation time they would save with shared files is probably
>> less than the time that they would spend on managing the projects.)
>
> We don't use project files to save compilation time.  We do it to:
>
> a) reuse shared libraries

The customers I was referring to simply make copies of the shared files. My 
understanding is they had a strong process about modifying them, and a 
simple way to refresh those copies when needed.

> b) direct the compiler at the proper target-specific package bodies

I haven't talked about this, but it would be the same.

>> YMMV, of course, but I think "one-button builds" from raw (and
>> portable) source code is the ideal way to go.
>
> Agreed.
>
>> I'm now looking at ways to make that easier with Janus/Ada (one
>> obvious way is to eliminate the need for any special naming
>> conventions for Ada source code).
>
> How would you handle multiple available bodies for the same package?  (I
> imagine it would turn it into at least a "two-button build".)

My presumption is that every target would have a separate copy of the source 
code, with the appropriate bodies. That copy would be refreshed from the 
version control as needed (and that's outside of what Janus/Ada is concerned 
about). One hopes that the version control has an easy way to get shared 
files and separate bodies easily. (That's the main reason that we built our 
own front-end to CVS; to me, a project is a web of shared files (including 
specifications) and unshared bodies; we needed a way to get all of the files 
for, say, an MS-DOS target and we needed to be able to develop all of those 
targets at one time. Conventional branching is just too ad-hoc and too hard 
to use for that, because you have a whole series of files with bodies 
specifically for different targets (and all of which need to be updated in 
parallel).

Anyway, there are a lot of ways to do this sort of thing, and its doubtful 
that one size would fit all (or even many).

                                         Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Vasiliy Molostov" <molostoff@gmail.com> wrote in message 
news:op.wius1gdbka8ora@aspire.local...
>Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Sat, 11 Aug 
>2012 04:46:59 +0400:
>
>> YMMV, of course, but I think "one-button builds" from raw (and portable)
>> source code is the ideal way to go. I'm now looking at ways to make that
>> easier with Janus/Ada (one obvious way is to eliminate the need for any
>> special naming conventions for Ada source code).
>
>Does it means that there would be a something like intermediate database 
>(e.g. index)?

We don't call it a database, but Janus/Ada has long had a "project file" 
that holds various compilation information, mostly for the benefit of the 
CORDER tool. It's a binary, block-formatted file, and we use it for a 
variety of purposes. The biggest problem with it is that it can't be 
modified outside of the Janus/Ada toolset; it's mainly intended to be used 
in the background with very little interaction. That's not always what 
customers want.

                                    Randy.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Randy Brukardt <randy@rrsoftware.com> писал(а) в своём письме Tue, 14 Aug  
2012 02:16:00 +0400:
> it's mainly intended to be used
> in the background with very little interaction. That's not always what
> customers want.
>
>                                     Randy.

Why not to turn/move it into xml?


-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Monday, August 13, 2012 8:52:20 PM UTC-6, Vasiliy Molostov wrote:
> Randy Brukardt <randy@rrsoftware.com> писал(а) в своём письме Tue, 14 Aug  
> 2012 02:16:00 +0400:
> 
> > it's mainly intended to be used
> > in the background with very little interaction. That's not always what
> > customers want.
> >
> >                                     Randy.
> 
> Why not to turn/move it into xml?

Because XML is a dirty, dirty format. 

There's truth, perhaps more than a bit, in this humor:

"XML is like violence. Sure, it seems like a quick and easy solution at first, but then it spirals out of control into utter chaos." -- Sarkos in reddit

"XML combines the efficiency of text files with the readability of binary files" -- unknown


And less humorous:
"Transformations, even identity transforms, result in changes to format (whitespace, attribute ordering, attribute quoting, whitespace around attributes, newlines). These problems can make "diff"ing the XML source very difficult." -- http://c2.com/cgi/wiki?XmlSucks

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Tue, 14 Aug 2012 07:44:42 -0700 (PDT), Shark8 wrote:

> "XML combines the efficiency of text files with the readability of binary files" -- unknown

That one was great! (:-)) 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 14.08.12 16:44, Shark8 wrote:
> On Monday, August 13, 2012 8:52:20 PM UTC-6, Vasiliy Molostov wrote:
>> Randy Brukardt <randy@rrsoftware.com> писал(а) в своём письме Tue, 14 Aug  
>> 2012 02:16:00 +0400:
>>
>>> it's mainly intended to be used
>>> in the background with very little interaction. That's not always what
>>> customers want.
>>>
>>>                                     Randy.
>>
>> Why not to turn/move it into xml?
> 
> Because XML is a dirty, dirty format. 
> 
> There's truth, perhaps more than a bit, in this humor:
> 
> "XML is like violence. Sure, it seems like a quick and easy solution at first, but then it spirals out of control into utter chaos." -- Sarkos in reddit
> 
> "XML combines the efficiency of text files with the readability of binary files" -- unknown
> 
> 
> And less humorous:
> "Transformations, even identity transforms, result in changes to format (whitespace, attribute ordering, attribute quoting, whitespace around attributes, newlines). These problems can make "diff"ing the XML source very difficult." -- http://c2.com/cgi/wiki?XmlSucks
> 

Or, in other words, if programmers use XML as if it was
like program source text, XML turns out to be very different.

Wow. At least witty commentary compensates for the lack
of understanding of the basics of XML.

XML is not intended to be readable in the sense that Ada
was intended to be readable. Readable in the case of XML
means something more plain, something more technical:
that anyone can read XML documents using a pair of
eyes and a program like "more". No knowledge of any other
language is required, no knowledge of bit patterns is required.
Nor is XML intended for internal data formats.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Tue, 14 Aug 2012  
18:44:42 +0400:

> These problems can make "diff"ing the XML source very difficult." --  
> http://c2.com/cgi/wiki?XmlSucks

Probably if you have unclear view it is better to use xmldiff tool. Also,  
try to sucks against
Scala/Java/Groovy and friends - you might want to wonder where you stay  
with you opinion while others moving forward.

This is a description landuage rooted from its grandfather EDIF, being  
born in AutoCAD field as an interchange text file format. So the purpose  
is clear.

To get many tools capable to use compiler project/compilation/database it  
is the best choice. And a tremendous asis related interfaces can go to the  
bookshelf.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Tuesday, August 14, 2012 9:11:56 AM UTC-6, Georg Bauhaus wrote:
> 
> Or, in other words, if programmers use XML as if it was
> like program source text, XML turns out to be very different.

Who said anything about source-text? The problem with XML, besides parsing, is that it really does tend to spin out of control when you're using it.

One of my college group-projects was a virtual notebook [using SVG wrapped in XML for the 'pages'], written in Java. We were working with person/module style and I had the save/load module; I got it all coded up and my module was working pretty nicely but for some reason when we tried to integrate it into the program it suddenly wasn't working. Turns out the namespace attribute had to be set. That's right the presence/absence of that single [optional, according to the documentation, IIRC] attribute caused the whole thing to fail.

> Wow. At least witty commentary compensates for the lack
> of understanding of the basics of XML.

What's there to understand when you're evaluating it as a container?
Take config-files, they're usually much better stored in an INI file.
About the only thing I can really envision XML being appropriate for, and this is likely a stretch, would be serialization of [OOP]  objects where the tag would be either an object or a primitive type, a primitive type being self-closing and having a value attribute where the object-tag would enclose tags corresponding to its own fields (either object-tags or primitive-tags themselves)... of course that pretty much just described the text-format DFM files Delphi uses (which I like more because of their readability and philosophy of "if it's the default, don't save it" which is sadly missing from a lot of config/state/obj serializations).

> 
> XML is not intended to be readable in the sense that Ada
> was intended to be readable.

Yes, it was; both were meant to be human readable.
Though if you meant the emphasis of readability was not the same I would agree: XML is skewed toward the machine away from the human, at least in use.

> Readable in the case of XML
> means something more plain, something more technical:
> that anyone can read XML documents using a pair of
> eyes and a program like "more". No knowledge of any other
> language is required, no knowledge of bit patterns is required.

And that's where XML often fails. Sure you "can*, as in might be able to, operate an XML file with a plain-text viewer -- but again, once there's any real-life complexity, then the relevant information [the signal] is quickly lost in a sea of noise.

This is why INI files beat XML as config files: there is so little noise built into the format of "sections containing key/value pairs."

> Nor is XML intended for internal data formats.

That doesn't stop people from doing so; I've seen it in web-programs and desktop apps (a lot more now that MS-Office's *.???x format is widespread).

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Tuesday, August 14, 2012 9:19:02 AM UTC-6, Vasiliy Molostov wrote:
> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Tue, 14 Aug 2012  
> 
> 18:44:42 +0400:
> 
> > These problems can make "diff"ing the XML source very difficult." --  
> > http://c2.com/cgi/wiki?XmlSucks
> 
> Probably if you have unclear view it is better to use xmldiff tool. Also,  
> try to sucks against
> Scala/Java/Groovy and friends - you might want to wonder where you stay  
> with you opinion while others moving forward.

Sometimes you simply don't have access to such tools, even if you're aware of them. But thank you for telling me about XMLdiff, I'll have to check it out next time I have to muck around with XML. (If I'm lucky that'll be "never again".)

> 
> This is a description landuage rooted from its grandfather EDIF, being  
> born in AutoCAD field as an interchange text file format. So the purpose  
> is clear.

Oh, I'm not saying it has an unclear purpose. I'm saying that it's a hard format to use nicely, to keep things correct with. Though I do pity those who have been forced to work projects where regexes are used on XML. (That seems to be a surprisingly common attempt, though it's not possible as it requires something more powerful; the same as between an FSM and PDA, map to those problems, IIRC.)

> 
> To get many tools capable to use compiler project/compilation/database it  
> is the best choice. And a tremendous asis related interfaces can go to the  
> bookshelf.

I don't think that's true. (That XML is the best choice for compilers to use, I mean; I haven't had cause to use ASIS so I can't comment on it.)

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1mchat48i3fos.1ksbz02nuzf5f$.dlg@40tude.net...
> On Tue, 14 Aug 2012 07:44:42 -0700 (PDT), Shark8 wrote:
>
>> "XML combines the efficiency of text files with the readability of binary 
>> files" -- unknown
>
> That one was great! (:-))

And accurate! Text files are quite a bit slower to access than binary files, 
which is OK if they are intended to be processed (read/modified) by humans. 
But XML is lousy at that (humans are not good at counting bracketing 
constructs).

                                       Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Vasiliy Molostov" <molostoff@gmail.com> wrote in message 
news:op.wi0fliuoka8ora@aspire.local...
> Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Tue, 14 Aug 
> 2012 02:16:00 +0400:
>> it's mainly intended to be used
>> in the background with very little interaction. That's not always what
>> customers want.
>
> Why not to turn/move it into xml?

Because XML is a classic solution in search of a problem?? :-)

The entire point of the file format is that it is a block-structured 
random-access file (that is, Direct_IO); the compiler only accesses the 
records it needs, not the whole file. (The whole file can get quite large if 
a lot of compilation units are involved, I've seen files with 10000 
records.) Reading the entire file, especially if it is large, would be 
prohibitive. Reading it as a *text* file, which would be 3-5 times slower 
than pure binary, would be insane.

I suppose one could use blank-padding to make each record the same size 
(thus allowing random access), and put snippets of XML in each record. But I 
don't quite see the point; one couldn't create or modify such a file with 
standard tools (which would not preserve the required blanks).

Janus/Ada was designed to run on tiny host machines (like MS-DOS was), and 
as such we don't use text for anything (simply because it would take a lot 
more code to read and write than binary records do). We don't need to worry 
about hosts without decent amounts of memory anymore, but redesigning 
everything to use text files -- which still should never be modified by a 
human -- and making it a lot slower in the process -- doesn't really make 
much sense.

                                                               Randy.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Randy Brukardt <randy@rrsoftware.com> писал(а) в своём письме Wed, 15 Aug  
2012 02:16:10 +0400:

> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message
> news:op.wi0fliuoka8ora@aspire.local...
>> Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Tue, 14

> about hosts without decent amounts of memory anymore, but redesigning
> everything to use text files -- which still should never be modified by a
> human -- and making it a lot slower in the process -- doesn't really make
> much sense.
>
>                                                                Randy.

The goal perhaps can be not an efficiency on tiny memory host, but  
interface to a rich xml toolset that can
be used by a customer to extract project related data in a manner much  
simper than asis related stuff. Suppose this xml is a form (subclass)
of xmi files capable to be read by modern uml modelling tools - ? a  
customer has an ability to get and control such data
in a modelling tool directly, whose for now have a bunch of "deployment"  
abstractions. from some point of view this capability is obvious.

And why you have assumed that old code should be removed, you dont like it?

>
>


-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Wed, 15 Aug 2012  
00:41:06 +0400:

> On Tuesday, August 14, 2012 9:19:02 AM UTC-6, Vasiliy Molostov wrote:
>> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Tue, 14 Aug  
>> 2012

> Oh, I'm not saying it has an unclear purpose. I'm saying that it's a  
> hard format to use nicely, to keep things correct with. Though I do pity  
> those who have been forced to work projects where regexes are used on  
> XML. (That seems to be a surprisingly common attempt, though it's not  
> possible as it requires something more powerful; the same as between an  
> FSM and PDA, map to those problems, IIRC.)

xml is not for human, it is interchange format, e.g. between applications,  
machines, tools etc.
and has nice and rich auto-validation capabilities.

> I don't think that's true. (That XML is the best choice for compilers to  
> use, I mean; I haven't had cause to use ASIS so I can't comment on it.)

it is a reality, and not a matter to trust it's true or not.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Tuesday, August 14, 2012 5:59:47 PM UTC-6, Vasiliy Molostov wrote:
> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Wed, 15 Aug 2012  
> 00:41:06 +0400:
> 
> > On Tuesday, August 14, 2012 9:19:02 AM UTC-6, Vasiliy Molostov wrote:
> >> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Tue, 14 Aug  
> >> 2012
> 
> > Oh, I'm not saying it has an unclear purpose. I'm saying that it's a  
> > hard format to use nicely, to keep things correct with. Though I do pity  
> > those who have been forced to work projects where regexes are used on  
> > XML. (That seems to be a surprisingly common attempt, though it's not  
> > possible as it requires something more powerful; the same as between an  
> > FSM and PDA, map to those problems, IIRC.)
> 
> 
> xml is not for human, it is interchange format, e.g. between applications,  
> machines, tools etc.
> and has nice and rich auto-validation capabilities.

Which are routinely subverted by those that break out regex as their "parser" of choice. Further it is a horrible format for random-access, as Randy pointed out, requiring a read-through (parsing) for anything; even if you know exactly *where* in your tree-structure it is. {By being in text-format you lose a *lot* of desirable properties.} This is what makes it unsuitable for many data-intensive applications. I had the chance to work with Combat XXI a few years back --absolutely HUGE Java-program; so much so that ANT couldn't auto-compile it in one go and I needed to write a utility to generate sub-make instructions iterating over the subdirectory tree, leaves-to-root, to ensure that everything compile-- as I was talking to one of the other devs they mentioned that they had to write a binary-equivalent of XML for saving the simulation... because saving as text made the load too slow, and the text bloated the file-sizes to unacceptable levels.

So, even where I concede that XML may be useful (storing objects and their states) it has shortcomings. {Some parsers require keeping the XML structure in-memory; this creates a similar problem as Combat XXI's run-saving, but becomes a problem much earlier: most computers don't have a dozen GB to throw around at a problem.}

> 
> > I don't think that's true. (That XML is the best choice for compilers to  
> > use, I mean; I haven't had cause to use ASIS so I can't comment on it.)
> it is a reality, and not a matter to trust it's true or not.

Given the above [counter-]example, I believe that I have at least given enough evidence to cause one to rethink that statement. A compiler needs a lot of information, true; but that doesn't mean that such information should be bloated by its transport-layer -- that would be like applying multiple analog-to-digital and digital-to-analog conversions in audio systems: doing a lot of work for nothing, that A-to-D step should happen only once, and [some of] the most hardcore audiophiles will invest in things on the analog side of the switch, which is why you can find amplifiers using vacuum-tubes.)

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Wed, 15 Aug 2012  
04:50:14 +0400:

> On Tuesday, August 14, 2012 5:59:47 PM UTC-6, Vasiliy Molostov wrote:
>> Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Wed, 15 Aug  
>> 2012

> Which are routinely subverted by those that break out regex as their  
> "parser" of choice. Further it is a horrible format for random-access,  
> as Randy pointed out, requiring a read-through (parsing) for anything;

For a developer it is a matter of one index file to parse it only once, if  
this is a problem.

> even if you know exactly *where* in your tree-structure it is. {By being  
> in text-format you lose a *lot* of desirable properties.}

Which ones? EOF delimiters?

> This is what makes it unsuitable for many data-intensive applications.

All the web for today works on top of xml, btw. it is very data-intensive.

> I had the chance to work with Combat XXI a few years back --absolutely  
> HUGE Java-program; so much so that ANT couldn't auto-compile it in one  
> go and I needed to write a utility to generate sub-make instructions  
> iterating over the subdirectory tree, leaves-to-root, to ensure that  
> everything compile-- as I was talking to one of the other devs they  
> mentioned that they had to write a binary-equivalent of XML for saving  
> the simulation...

Perhaps you are a second man complaining about broken ant builder, one of  
my friends also had similar problem indeed. Keeping such a binary for only  
one ant tool and loose all other constructive and profitable things is  
possibly a short-sighted solution, where indeed it is an internal ant  
problem.

> because saving as text made the load too slow, and the text bloated the  
> file-sizes to unacceptable levels.

...and depends on structure and content, at first.

> So, even where I concede that XML may be useful (storing objects and  
> their states) it has shortcomings. {Some parsers require keeping the XML  
> structure in-memory; this creates a similar problem as Combat XXI's  
> run-saving, but becomes a problem much earlier: most computers don't  
> have a dozen GB to throw around at a problem.}

xml is a stream oriented format, at first. Perhaps some not good  
implementation
should not revert an opinion on technology by itself. Badly programmed Ada  
package
can not express (invoke a claim) that Ada is bad itself for a whole.

> Given the above [counter-]example, I believe that I have at least given  
> enough evidence to cause one to rethink that statement. A compiler needs  
> a lot of information, true; but that doesn't mean that such information  
> should be bloated by its transport-layer

Transport? Why transport? Interchange layer.

> -- that would be like applying multiple analog-to-digital and  
> digital-to-analog conversions in audio systems: doing a lot of work for  
> nothing, that A-to-D step should happen only once, and [some of] the  
> most hardcore audiophiles will invest in things on the analog side of  
> the switch, which is why you can find amplifiers using vacuum-tubes.)

Interesting paragraph, but it does not relate to xml, xmi, uml or another  
development tool.
Perhaps you can get an example of use xml in ODT/ODF file format  
(previously binary) developed by
OASIS and widely used in MS/Libre world in packages like Openoffice, and  
even is a nation wide standard for now. I found it fast, accessible by
handy tools like scripting, like access from an ada application using  
xmlada or any other xml reader.

Another good example is a docbook format widely used in publishing  
industry. Even Dmitry A. Kazakov usually configures his hardware devices  
with xml based configurations (only imagine - xml parser in a device !!!  
:-O, lol how many things we can discover today ), to say more, at most all  
of ISP provider routers are controlled and configured over IGD protocol  
which is a subset of xml (indeed a wsdl). So perhaps a wind of changes  
already has gone, much time ago. We have xml based world here (on a  
development host).

And surprisingly, a copy conversion from one format to another gives no  
degraded quality - check it with google docs.

I think that a compilation result is not only a set of object files but  
also an automated report (standalone document) where all
actions undertaken and dependencies resolved by the compiler are simply  
described, so a typical customer (or even a compiler itself) can dig it  
and find data from it useful for his own tool/purpose.

The first and most useful thing here is an automated test generation, i  
suppose, and not a "project management".

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Simon Wright]

"Vasiliy Molostov" <molostoff@gmail.com> writes:

> The goal perhaps can be not an efficiency on tiny memory host, but
> interface to a rich xml toolset that can be used by a customer to
> extract project related data in a manner much simper than asis related
> stuff.

This was my motivation for ASIS2XML[1]. Aside, of course, from having
fun!

[1] http://gnat-asis.sourceforge.net/pmwiki.php/Main/ASIS2XML

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Tue, 14 Aug 2012 17:04:09 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
> news:1mchat48i3fos.1ksbz02nuzf5f$.dlg@40tude.net...
>> On Tue, 14 Aug 2012 07:44:42 -0700 (PDT), Shark8 wrote:
>>
>>> "XML combines the efficiency of text files with the readability of binary 
>>> files" -- unknown
>>
>> That one was great! (:-))
> 
> And accurate! Text files are quite a bit slower to access than binary files, 
> which is OK if they are intended to be processed (read/modified) by humans. 
> But XML is lousy at that (humans are not good at counting bracketing 
> constructs).

It has a vital psychological effect. Something simple to read and
understand will never be considered worth of money and efforts.

On the contrary, a highly complicated mess requiring a heap of tools
mounted on each other, is a cool thing. Clearly, spending man-centuries on
designing all the garbage must indicate its great value in all fields of
software engineering!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 15.08.12 09:51, Dmitry A. Kazakov wrote:
> On Tue, 14 Aug 2012 17:04:09 -0500, Randy Brukardt wrote:
> 
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
>> news:1mchat48i3fos.1ksbz02nuzf5f$.dlg@40tude.net...
>>> On Tue, 14 Aug 2012 07:44:42 -0700 (PDT), Shark8 wrote:
>>>
>>>> "XML combines the efficiency of text files with the readability of binary 
>>>> files" -- unknown
>>>
>>> That one was great! (:-))
>>
>> And accurate! Text files are quite a bit slower to access than binary files, 
>> which is OK if they are intended to be processed (read/modified) by humans. 
>> But XML is lousy at that (humans are not good at counting bracketing 
>> constructs).
> 
> It has a vital psychological effect. Something simple to read and
> understand will never be considered worth of money and efforts.
> 
> On the contrary, a highly complicated mess requiring a heap of tools
> mounted on each other, is a cool thing. Clearly, spending man-centuries on
> designing all the garbage must indicate its great value in all fields of
> software engineering!

Like the situation that created Ada, the situation before agreed-upon
means of data exchange between totally heterogeneous systems
had created a highly complicated mess. To get at some piece of
data it was required not only to have tools mounted each other,
not only to know what section of bits may mean what,
but integrating the mess also required a second order set of tools
to make the first order set of tools work together.

Fortunately, for non-internal data formats, getting at pieces of
information in "foreign" data is now possible in a validating
form by having the heterogeneous systems interchange data in
an agreed-upon simple, structured, descriptive format.

I would say that a network connecting the electrical devices
of a car does not counts as heterogeneous.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 14.08.12 22:30, Shark8 wrote:

> the presence/absence of that single [optional, according to the documentation, IIRC] attribute caused the whole thing to fail.

You don't remember correctly.

Namespaces used to be controversial, but an Ada-like solution
has been adopted by XML.

>> Wow. At least witty commentary compensates for the lack
>> of understanding of the basics of XML.
> 
> What's there to understand when you're evaluating it as a container?
> Take config-files, they're usually much better stored in an INI file.

Both "usually" and "much better" need facts to back them up.
If two heterogeneous systems need to exchange configuration
data, whether or not INI files will work well, or not at all,
or something in between, will depend on the configuration data.

> About the only thing I can really envision XML being appropriate for, and this is likely a stretch, would be serialization of [OOP]  objects where the tag would be either an object or a primitive type, a primitive type being self-closing and having a value attribute where the object-tag would enclose tags corresponding to its own fields (either object-tags or primitive-tags themselves)... of course that pretty much just described the text-format DFM files Delphi uses (which I like more because of their readability and philosophy of "if it's the default, don't save it" which is sadly missing from a lot of config/state/obj serializations).

While XML is being used for serialization between heterogeneous systems,
I guess that's probably because programmers have tools for turning
internal data objects into serialized form for external use, apparently
freeing them from thinking, and apparently saving some work at some point.
Nevertheless, this frees the other end from having to deal with foreign
internals.

> Though if you meant the emphasis of readability was not the same I would agree: XML is skewed toward the machine away from the human, at least in use.

Yes I meant "technically possible to read without additional
tools, everywhere".

>> Readable in the case of XML
>> means something more plain, something more technical:
>> that anyone can read XML documents using a pair of
>> eyes and a program like "more". No knowledge of any other
>> language is required, no knowledge of bit patterns is required.
> 
> And that's where XML often fails. Sure you "can*, as in might be able to, operate an XML file with a plain-text viewer -- but again, once there's any real-life complexity, then the relevant information [the signal] is quickly lost in a sea of noise.

Again, these claims would profit from facts to back them up:
Here is one. The real-life situation is exchange of data.
You need to debug one such exchange.
If (1) you get to see a stream of bits, what do they mean,
where is the error?
If (2) you get to see a structured text, what do the words mean,
where is the error?

> This is why INI files beat XML as config files: there is so little noise built into the format of "sections containing key/value pairs."

In this case, your ini files would be trivial, and your XML files would
be a product of thoughtlessness. Both are related to quality of work and data,
they do not imply properties inherent to either format,
as can be seen by actually comparing equals in either format:

[gnorplx]
foo = 42
thrndx = 1m

<gnorplx
  foo="42"
  thrndx="1m" />

Big deal? -- If the XML file should look even more like an INI
file, if your eyes sting when they see angle brackets in plain
text, then with a suitable SGML declaration for a config document,
the aesthetically offended programmer can write

[gnorplx]
foo = 42
thrndx = 1m

in SGML.

>> Nor is XML intended for internal data formats.
> 
> That doesn't stop people from doing so; I've seen it in web-programs and desktop apps (a lot more now that MS-Office's *.???x format is widespread).

Nor does the attribution of simplicity to INI, CSV, etc.
stop people from storing a ton of brittle implications
in these files, sometimes pointing out efficiency.
My favorite example: CSV without record separators
(hint: use counting).

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Wed, 15 Aug 2012 13:08:37 +0200, Georg Bauhaus wrote:

> I would say that a network connecting the electrical devices
> of a car does not counts as heterogeneous.

How are the ECU, navigation system, ABS, windshield wiper homogenous?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 15.08.12 13:55, Dmitry A. Kazakov wrote:
> On Wed, 15 Aug 2012 13:08:37 +0200, Georg Bauhaus wrote:
> 
>> I would say that a network connecting the electrical devices
>> of a car does not counts as heterogeneous.
> 
> How are the ECU, navigation system, ABS, windshield wiper homogenous?

They are homogeneous in that the 4 suppliers agree to be supplying
for the same 1 system, under the "umbrella-notion" of car
electronics.

Chances are that "it is understood" that the ways of data
communication in a car meet the expectations of electrical
engineering that all suppliers share. They will, I bet, all agree
that a PDF document sent to a windshield wiper will not be the most
effective way of controlling the thing.

A heterogeneous system in this sense is one where a supplier will
supply data to, say, anything, irrespective of how any one client is
going to process the data.  The umbrella-notion is different. Again,
PDFs may not be welcome as a carrier of data (although this happens).
XML documents allow for much better independent processing of data;
facilitating easy integration of data from very different sources,
sources even, whose existence you may want to hide from each other.

Joining the two worlds, some measuring instrument at a service
station, of any make and model, could be connected to the internet
to supply measurement statistics to just any contemporary business
information system.  The recipient gets to choose how to process the
data, but the mechanics of processing is already in place; no
worries about protocols, no questions regarding syntax.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Wed, 15 Aug 2012 17:49:01 +0200, Georg Bauhaus wrote:

> On 15.08.12 13:55, Dmitry A. Kazakov wrote:
>> On Wed, 15 Aug 2012 13:08:37 +0200, Georg Bauhaus wrote:
>> 
>>> I would say that a network connecting the electrical devices
>>> of a car does not counts as heterogeneous.
>> 
>> How are the ECU, navigation system, ABS, windshield wiper homogenous?
> 
> They are homogeneous in that the 4 suppliers agree to be supplying
> for the same 1 system, under the "umbrella-notion" of car
> electronics.

I see, not to forget that the gravitational constant is same too. That
evidently makes it homogenous...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 15.08.12 18:24, Dmitry A. Kazakov wrote:
> On Wed, 15 Aug 2012 17:49:01 +0200, Georg Bauhaus wrote:
> 
>> On 15.08.12 13:55, Dmitry A. Kazakov wrote:
>>> On Wed, 15 Aug 2012 13:08:37 +0200, Georg Bauhaus wrote:
>>>
>>>> I would say that a network connecting the electrical devices
>>>> of a car does not counts as heterogeneous.
>>>
>>> How are the ECU, navigation system, ABS, windshield wiper homogenous?
>>
>> They are homogeneous in that the 4 suppliers agree to be supplying
>> for the same 1 system, under the "umbrella-notion" of car
>> electronics.
> 
> I see, not to forget that the gravitational constant is same too. That
> evidently makes it homogenous...

Dropping the blinders will make you see how people decide
which data format is adequate under the respective circumstances.

I have tried to supply hooks for formalization of these
situational variables. Apply fuzzy logic.

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Wednesday, August 15, 2012 5:47:23 AM UTC-6, Georg Bauhaus wrote:
> On 14.08.12 22:30, Shark8 wrote:
> 
> 
> 
> > the presence/absence of that single [optional, according to the documentation, IIRC] attribute caused the whole thing to fail.
> 
> 
> 
> You don't remember correctly.
> Namespaces used to be controversial, but an Ada-like solution
> has been adopted by XML.

It was years ago, it might have been due to still being controversial, it may also have have been the Java documentation was wrong, and, yes, I could have been recalling wrong.

> 
> >> Wow. At least witty commentary compensates for the lack
> >> of understanding of the basics of XML.
> > 
> 
> > What's there to understand when you're evaluating it as a container?
> > Take config-files, they're usually much better stored in an INI file.
> 
> Both "usually" and "much better" need facts to back them up.

I'm using my own experience as a gauge; it is incorrect to not consider experience as fact. -- True, my perceptions color things, but you simply cannot say that the experiences didn't happen.

> If two heterogeneous systems need to exchange configuration
> data, whether or not INI files will work well, or not at all,
> or something in between, will depend on the configuration data.

Agreed. INI files would be horrible for storing the state of a simulation, as would most text-based files, also it would not suit data which is hierarchical like object-serialization (in particular the 'has-a' relation). 

> 
> > About the only thing I can really envision XML being appropriate for, and this is likely a stretch, would be serialization of [OOP]  objects where the tag would be either an object or a primitive type, a primitive type being self-closing and having a value attribute where the object-tag would enclose tags corresponding to its own fields (either object-tags or primitive-tags themselves)... of course that pretty much just described the text-format DFM files Delphi uses (which I like more because of their readability and philosophy of "if it's the default, don't save it" which is sadly missing from a lot of config/state/obj serializations).
> 
> While XML is being used for serialization between heterogeneous systems,
> I guess that's probably because programmers have tools for turning
> internal data objects into serialized form for external use, apparently
> freeing them from thinking, and apparently saving some work at some point.

I would agree; though there are problems about not-thinking in [my experience] in the field (granted, I was doing web-site backend stuff).

> Nevertheless, this frees the other end from having to deal with foreign
> internals.

Which is not a bad thing; good tools allow the user to concentrate on the job rather than on particular irrelevancies. I don't like working on *nix systems precisely because of this problem: the irrelevancies get in the way much too often. (File-permissions is a good example; the one and ONLY time I've had a file-permission issue get in the way of working on a Windows-system was under a *nix subsystem port [Ming].)

> 
> > Though if you meant the emphasis of readability was not the same I would agree: XML is skewed toward the machine away from the human, at least in use.
> 
> Yes I meant "technically possible to read without additional
> tools, everywhere".
> 
> >> Readable in the case of XML
> >> means something more plain, something more technical:
> >> that anyone can read XML documents using a pair of
> >> eyes and a program like "more". No knowledge of any other
> >> language is required, no knowledge of bit patterns is required.
> > 
> > And that's where XML often fails. Sure you "can*, as in might be able to, operate an XML file with a plain-text viewer -- but again, once there's any real-life complexity, then the relevant information [the signal] is quickly lost in a sea of noise.
> 
> 
> Again, these claims would profit from facts to back them up:
> Here is one. The real-life situation is exchange of data.
> You need to debug one such exchange.
> 
> If (1) you get to see a stream of bits, what do they mean,
> where is the error?
> 
> If (2) you get to see a structured text, what do the words mean,
> where is the error?

As we're talking of XML in particular, I should think the second is the only class we really need to worry about. (Failure on the first would indicate a failure on transport or decoding-to-text; i.e. exceptional circumstance.)

> 
> > This is why INI files beat XML as config files: there is so little noise built into the format of "sections containing key/value pairs."
> 
> In this case, your ini files would be trivial, and your XML files would
> be a product of thoughtlessness. Both are related to quality of work and data,
> they do not imply properties inherent to either format,
> 
> as can be seen by actually comparing equals in either format:
> 
> [gnorplx]
> foo = 42
> thrndx = 1m
> 
> <gnorplx
>   foo="42"
>   thrndx="1m" />

This is trivial, but indicates a problem about the XML format: it assumes everything to be a tree. Element gnorplx here is representing an entire section of the given INI -- the key-value pairs though should be leaves themselves of the section-object.

INI files have a different problem: they assume things to be non-hierarchical, key-value pairs divided into sections.

> 
> Big deal? -- If the XML file should look even more like an INI
> file, if your eyes sting when they see angle brackets in plain
> text, then with a suitable SGML declaration for a config document,
> the aesthetically offended programmer can write
> 
> [gnorplx]
> foo = 42
> thrndx = 1m
> 
> in SGML.

Er, that's a pretty bad example. It's like saying you CAN serialize objects into INI-format w/o considering the consequences of that decision. Indeed, that's been my main underlying point here: XML carries with it implicit costs, it is *not* the best solution for every problem. {It is my opinion that there are very few problems that it actually does solve nicely: object-serialization is one where I think it is adequate. (Though, as CombatXXI shows, it may be unsuitable for that due to constraints.)}

> 
> >> Nor is XML intended for internal data formats.
> > 
> > That doesn't stop people from doing so; I've seen it in web-programs and desktop apps (a lot more now that MS-Office's *.???x format is widespread).
> 
> Nor does the attribution of simplicity to INI, CSV, etc.
> stop people from storing a ton of brittle implications
> in these files, sometimes pointing out efficiency.

Ive not seen "efficiency" *ever* cited as a choice's decision-factor for either CSV or INI -- I have, however, seen "portability" and "simplicity" cited. {Especially in CSV vs Excel's binary decoding for importing data into a system.}

> 
> My favorite example: CSV without record separators
> (hint: use counting).

Yeah, I haven't encountered CSV w/o record separation... I have encountered the other-way that makes record separators irrelevant though: data across multiple rows for a single record -- Which is why people who use spreadsheets when they should be using DBs ought to be beaten. {I say that having had some little experience on the Army's admin side: what a nightmare of using the wrong tools for the job.}

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Wed, 15 Aug 2012 18:53:09 +0200, Georg Bauhaus wrote:

> On 15.08.12 18:24, Dmitry A. Kazakov wrote:
>> On Wed, 15 Aug 2012 17:49:01 +0200, Georg Bauhaus wrote:
>> 
>>> On 15.08.12 13:55, Dmitry A. Kazakov wrote:
>>>> On Wed, 15 Aug 2012 13:08:37 +0200, Georg Bauhaus wrote:
>>>>
>>>>> I would say that a network connecting the electrical devices
>>>>> of a car does not counts as heterogeneous.
>>>>
>>>> How are the ECU, navigation system, ABS, windshield wiper homogenous?
>>>
>>> They are homogeneous in that the 4 suppliers agree to be supplying
>>> for the same 1 system, under the "umbrella-notion" of car
>>> electronics.
>> 
>> I see, not to forget that the gravitational constant is same too. That
>> evidently makes it homogenous...
> 
> Dropping the blinders will make you see how people decide
> which data format is adequate under the respective circumstances.
> 
> I have tried to supply hooks for formalization of these
> situational variables. Apply fuzzy logic.

Formal by which measure? And how does it make car's devices homogenous? And
how these false premises could justify any application of XML even if per
some miracle they happened true?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 15.08.12 20:53, Dmitry A. Kazakov wrote:
> And
> how these [unsubstantiated claim] justify any application of XML even if per
> some miracle they happened true?

I'll answer in another post, but here is a business idea
involving cars, XML, and smart phones.

I don't know if it is new and I won't be surprised if it is not
new (my car is rather old, in any case).  Since I do not currently
know anyone who works in the car industry so he could say "boring"
to me, here it is, and it is _not_ remote control:

Make cars send status data for to my mobile phone's
browser.

That is, send vehicle status data for regular guys.

For example,

- Battery status.

- Are the lights off (including parking lamps)?

- Where is my car?

- Anything you auto electricians can think of :-)


While remote control of home appliances doesn't seem to sell so
well, I imagine a nice car status display on the phone might find
a few friends.

Technically, then, have the car have a small web server
(perhaps smaller than AWS), and have the server send an XML
document to the owner's mobile phone. Have that triggered
by web  requests. Add information in caches as necessary.

The phone's browser software will have no trouble to show the
car's status nicely, possibly with the help of an XSLT
referenced in an XML-PI. Add links to the car's makers'
company web site. Or to the next repair shop.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 15.08.12 20:53, Dmitry A. Kazakov wrote:
> On Wed, 15 Aug 2012 18:53:09 +0200, Georg Bauhaus wrote:
>
>> On 15.08.12 18:24, Dmitry A. Kazakov wrote:
>>> On Wed, 15 Aug 2012 17:49:01 +0200, Georg Bauhaus wrote:
>>>
>>>> On 15.08.12 13:55, Dmitry A. Kazakov wrote:
>>>>> On Wed, 15 Aug 2012 13:08:37 +0200, Georg Bauhaus wrote:
>>>>>
>>>>>> I would say that a network connecting the electrical devices
>>>>>> of a car does not counts as heterogeneous.
>>>>>
>>>>> How are the ECU, navigation system, ABS, windshield wiper homogenous?
>>>>
>>>> They are homogeneous in that the 4 suppliers agree to be supplying
>>>> for the same 1 system, under the "umbrella-notion" of car
>>>> electronics.
>>>
>>> I see, not to forget that the gravitational constant is same too. That
>>> evidently makes it homogenous...
>>
>> Dropping the blinders will make you see how people decide
>> which data format is adequate under the respective circumstances.
>>
>> I have tried to supply hooks for formalization of these
>> situational variables. Apply fuzzy logic.
>
> Formal by which measure?

They are formal by any measure that relevant sciences have
produced from material evidence, and that can be tested by
observing reality. (They allow theorems using If-Then,
TheMore-TheLess, ceteris paribus, ...)

> And how does it make car's devices homogenous?

Homogeneous by all important points of view, see below.

> And
> how these false premises could justify any application of XML even if per
> some miracle they happened true?

The point of the exercise is to make apparent the variables
that help decide when, and when not, to use XML, based on
a measure of homogeneity *of* systems, not a measure of
perceived homogeneity or heterogeneity of devices *within*
*a* system ("system" as in "car's electronics").

:non-Ada.

Anyway, how can an ECU and a windshield wiper be homogeneous?
I'll try an elaborate answer although the answer seems obvious,
from a distance. And distance is a measure, needless to say!

Car electronics, by the very fact that this classification exists,
establishes a class of things that are of the same kind (homogeneous).
This requires a measure of sameness. There are several variables.
This is somewhat ad-hoc, but it leads to ways of measuring sameness.

With regard to the format of data exchange in a network, I imagine
there are at least these:

1) The equivalence class of car engineers establishes expectations.
These are likely sensible, based on technical knowledge and
experience, modulo personal preferences.

For example, making the car's wires transport Word documents
to the windshield wipers is likely considered absurd by every
engineer, XML is likely considered pointless by almost all
engineers, and then there will be interesting descriptions of
data formats by several engineers. [-All, -Almost_All, +Several;
more are of the same opinion (against Word or XML)]

2a) locality of networks,
2b) properties of connections,
2c)control of wires
establish, and limit, technical possibilities, [Length, Quality,
Predictability; e.g. every device is connected within the same
thing of 2x2x5 units of length, and unlike a web server of
a public library, the stop lamps cannot be offline between
1:00 AM and 3:00 AM]

3) all parties involved my communicate the data formats to be
used by others [E.g., REST services are of a different kind]

4) swiftness of data processing [Latency, Number of layers]




  

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Wed, 15 Aug 2012 23:29:01 +0200, Georg Bauhaus wrote:

> On 15.08.12 20:53, Dmitry A. Kazakov wrote:

>> And how does it make car's devices homogenous?
> 
> Homogeneous by all important points of view, see below.

Which points are as relevant to the car electronic infrastructure
homogeneity as the gravitational constant is. Otherwise, see:

http://encyclopedia2.thefreedictionary.com/homogeneous+network

>> And
>> how these false premises could justify any application of XML even if per
>> some miracle they happened true?
> 
> The point of the exercise is to make apparent the variables
> that help decide when, and when not, to use XML,

List of the variables, please.

> based on
> a measure of homogeneity *of* systems, not a measure of
> perceived homogeneity or heterogeneity of devices *within*
> *a* system ("system" as in "car's electronics").

Good luck driving "systems", but, incidentally, the only thing that you
could actually sit into and steer is that pesky car full of "perceived"
electronics. 

How is the choice XML vs., say, CANopen motivated by specifically
homogeneity?

What is homogenous by XML, which is not by other protocols, and conversely?

Which weight has the above [quantitative? qualitative?] difference in the
context of the requirements, functional and non-functional, imposed on the
car software infrastructure?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 16.08.12 09:30, Dmitry A. Kazakov wrote:
> On Wed, 15 Aug 2012 23:29:01 +0200, Georg Bauhaus wrote:
> 
>> On 15.08.12 20:53, Dmitry A. Kazakov wrote:
> 
>>> And how does it make car's devices homogenous?
>>
>> Homogeneous by all important points of view, see below.
> 
> Which points are as relevant to the car electronic infrastructure
> homogeneity as the gravitational constant is. Otherwise, see:
> 
> http://encyclopedia2.thefreedictionary.com/homogeneous+network
> 
>>> And
>>> how these false premises could justify any application of XML even if per
>>> some miracle they happened true?
>>
>> The point of the exercise is to make apparent the variables
>> that help decide when, and when not, to use XML,
> 
> List of the variables, please.

They were given in the text, and even indicated syntactically.

I had hoped that someone with a PhD in mathematics would find
this a fair read, even when the subject matter might look strange
at first sight.
There may be some correlations among the variables, and as
usual one cannot approach a complex subject empirically without
multivariate analysis of everything that will drive decisions.


> Good luck driving "systems", but, incidentally, the only thing that you
> could actually sit into and steer is that pesky car full of "perceived"
> electronics. 

Yes, so what. Back to the subject matter.

> How is the choice XML vs., say, CANopen motivated by specifically
> homogeneity?

By a homogeneity that I have outlined when talking about measures
of sameness, in the context of the situation, which is full of motives.

> What is homogenous by XML, which is not by other protocols, and conversely?

XML is not a protocol, but that's an aside.

I did not say anything about XML being a measure of homogeneity
other than maybe that XML, if chosen, can be one means of tackling
heterogeneity of data in situations outlined.

I think I'm not going to be sidetracked this time.


> Which weight has the above [quantitative? qualitative?] difference in the
> context of the requirements, functional and non-functional, imposed on the
> car software infrastructure?

Yes, as I said, apply fuzzy logic, and doing so stipulates
that the persons involved can produce weights that work.
Actually, I am sure they have done so many times.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Thu,  
16 Aug 2012 15:18:28 +0400:

> On 16.08.12 09:30, Dmitry A. Kazakov wrote:
>> On Wed, 15 Aug 2012 23:29:01 +0200, Georg Bauhaus wrote:

> XML is not a protocol, but that's an aside.

I am not sure that I understand clearly current state of the question with  
gravity/homogeneousness or other similar things. But, I think that xml  
format offers very important feature - validation. And even offers a third  
party validation (not target or source, e.g. data producer/consumer,  
sender/receiver) - it can be validated by a set of rules defined in a  
separate xml file, e.g. can have a schema definition. It is very important  
for strong typing system (ada application) to consume some input data  
after it is accepted as valid.

The goal for these "lazy" scripting methods - minimize effort on writing  
ada code for this utility purpose, since appropriate tools are already  
available.

I mean a development side of this stuff, not a production (e.g. computing  
and controlling in a car or satellite) - development becomes less time  
expensive with scripting access to the important data about program units  
(for example - a type tree, a package tree structure, class/object  
inheritance tree and so on).

We can do this using asis (if a compiler supports it accordingly), but  
with gnat we have to update each version with gnat/gcc/asis version  
update. This involves potentially a mistake about obtained data, which  
require more attention than it should take. These three are to perky to be  
constantly fixed for a long life cycle, due to regular gcc updates.
So the common benefit for xml - is an independent, self-contained  
validation. As of gnat there is a problem with gnatpp (for example) shows  
that the kitchen has missing some useful tool.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Thu, 16 Aug 2012 13:18:28 +0200, Georg Bauhaus wrote:

> On 16.08.12 09:30, Dmitry A. Kazakov wrote:
>> On Wed, 15 Aug 2012 23:29:01 +0200, Georg Bauhaus wrote:
>> 
>>> On 15.08.12 20:53, Dmitry A. Kazakov wrote:
>> 
>>>> And
>>>> how these false premises could justify any application of XML even if per
>>>> some miracle they happened true?
>>>
>>> The point of the exercise is to make apparent the variables
>>> that help decide when, and when not, to use XML,
>> 
>> List of the variables, please.
> 
> They were given in the text, and even indicated syntactically.

What you listed was unrelated to the issue. The decision must be based on
the immanent features of the protocols in question.

> I had hoped that someone with a PhD in mathematics would find
> this a fair read, even when the subject matter might look strange
> at first sight.

If has nothing to do with strangeness. There is a standard procedure of
evaluating such things in engineering. You should:

1. state the problem
2. present relevant criteria to evaluate a solution
3. present competing solutions > 1 (proving them solving the problem)
4. evaluate these solutions against the criteria
5. make choice based on the ranking obtained

>> How is the choice XML vs., say, CANopen motivated by specifically
>> homogeneity?
> 
> By a homogeneity that I have outlined when talking about measures
> of sameness, in the context of the situation, which is full of motives.

See above and go from 1 though to 5.

>> What is homogenous by XML, which is not by other protocols, and conversely?
> 
> XML is not a protocol, but that's an aside.

If you say that XML is not a protocol, then the train stops right here. We
were talking about the network of car devices. I don't care what else XML
might be, because being not a protocol automatically disqualifies it here
and now.

>> Which weight has the above [quantitative? qualitative?] difference in the
>> context of the requirements, functional and non-functional, imposed on the
>> car software infrastructure?
> 
> Yes, as I said, apply fuzzy logic,

You seem to imply that fuzzy logic (in its scientific meaning) acts
differently from crisp logic by allowing any sorts of non sequitur. It does
not.

> and doing so stipulates
> that the persons involved can produce weights that work.
> Actually, I am sure they have done so many times.

In that case you should summarize/cite their results. You brought the issue
of "homogeneity" up as a criterion of choice in favor of XML. Did you?

So I am merely asking for:

A) the definition of, because yours is absolutely non-standard
B) methodic of its evaluation
C) signs of importance for the considered case (car electronics network)
D) comparison to competing solutions

The joke an unknown author made about XML worked because it mocked the
process 1-5:

"XML combines the efficiency of text files with the readability of binary
files"

You find here all components: the competing solutions, the criteria, their
evaluation all leading to the hilarious choice of the worst possible
solution, which also makes a deeper point that there actually exists no
technical problem for which XML might be a proper solution. Very so!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 16.08.12 14:56, Dmitry A. Kazakov wrote:
> On Thu, 16 Aug 2012 13:18:28 +0200, Georg Bauhaus wrote:
> 
>> On 16.08.12 09:30, Dmitry A. Kazakov wrote:
>>> On Wed, 15 Aug 2012 23:29:01 +0200, Georg Bauhaus wrote:
>>>
>>>> On 15.08.12 20:53, Dmitry A. Kazakov wrote:
>>>
>>>>> And
>>>>> how these false premises could justify any application of XML even if per
>>>>> some miracle they happened true?
>>>>
>>>> The point of the exercise is to make apparent the variables
>>>> that help decide when, and when not, to use XML,
>>>
>>> List of the variables, please.
>>
>> They were given in the text, and even indicated syntactically.
> 
> What you listed was unrelated to the issue.

It was related to the issue from which you keep dragging
the discussion away: data formats.

I'll note in advance that your train might have stopped,
but you have missed ours, which has a different destination.

(I will give an example about distributed production of software,
if requested.)


>> I had hoped that someone with a PhD in mathematics would find
>> this a fair read, even when the subject matter might look strange
>> at first sight.
> 
> If has nothing to do with strangeness. There is a standard procedure of
> evaluating such things in engineering. You should:
> 
> 1. state the problem

Heterogeneous sources of data. (E.g. Teletext there + XML there)

> 2. present relevant criteria to evaluate a solution

Situational, given, as mentioned, e.g. integration of data.

> 3. present competing solutions > 1 (proving them solving the problem)

Given. (E.g., what has been done a few times: move from Teletext
to CSV to XML)

> 4. evaluate these solutions against the criteria

Ergo.

> 5. make choice based on the ranking obtained

Situational, e.g. as above.


>>> How is the choice XML vs., say, CANopen motivated by specifically
>>> homogeneity?
>>
>> By a homogeneity that I have outlined when talking about measures
>> of sameness, in the context of the situation, which is full of motives.
> 
> See above and go from 1 though to 5.

I did. Again.

>>> What is homogenous by XML, which is not by other protocols, and conversely?
>>
>> XML is not a protocol, but that's an aside.
> 
> If you say that XML is not a protocol, then the train stops right here.

OK. Your train stops.

> We
> were talking about the network of car devices.

I was not talking about protocols. Please re-read the posting

Message-ID: <502b832f$0$6579$9b4e6d93@newsspool3.arcor-online.net>

which started this sub-discussion. See in particular how does *not*
mention protocols at all.

> I don't care what else XML
> might be,

Your choice.

> because being not a protocol automatically disqualifies it here
> and now.

Yes, like I said, most engineers would heartily agree. See [+Almost all]
in a previous posting.


> You seem to imply that fuzzy logic (in its scientific meaning) acts
> differently from crisp logic by allowing any sorts of non sequitur.

No. There is a point when switching data formats to something
general like XML is considered by some programming projects.
This point is found in [0, 1] ⊂ R. A Yes (1) or No (0) is really
the consequence of a final preference and this preference's value
need not be 0 or 1.


>> and doing so stipulates
>> that the persons involved can produce weights that work.
>> Actually, I am sure they have done so many times.
> 
> In that case you should summarize/cite their results. You brought the issue
> of "homogeneity" up as a criterion of choice in favor of XML. Did you?

On the contrary, I said that XML, if chosen, is a way of
tackling heterogeneity of data. (E.g., moving away from Teletext
to XML sent over HTTP.) With Teletext, I have had to find means
of inspecting a mostly unknown stream of video text data.
Its bits and pieces were partially documented. This was enough
to write a crude scanner. With XML, I can at just read
the stuff and see some familiar vocabulary being used. Done.

> So I am merely asking for:
> 
> A) the definition of, because yours is absolutely non-standard

Homogeneity is a pre-network term and means, as mentioned many times,
of the same kind. (όμοιοϛ and γένοϛ are the parts of the word, TTBOMK.)
Where "kind" is from a multidimensional space of motivating factors.

> B) methodic of its evaluation

Multivariate analysis of those variables of the programming situation
that lead to a decision about data formats.

> C) signs of importance for the considered case (car electronics network)

I said, after establishing background, which see, that "a network
connecting the electrical devices of a car does not counts
as heterogeneous." A statement valid against the background only.

And that, therefore, one of the reasons for choosing XML does
*not* apply.

> D) comparison to competing solutions

See above, and everything said so far.

> The joke an unknown author made about XML worked because it mocked the
> process 1-5:
> 
> "XML combines the efficiency of text files with the readability of binary
> files"

It works only for those people who would declare the truth of
false statements about XML, mistaking the meanings of nouns
(deliberately?):

1. that readability means more than "can be read, technically, with
plain text tools", (it means little more than that)
2. that XML had been developed to be more efficient than other
data formats. (It has not.)

> You find here all components: the competing solutions, the criteria, their
> evaluation all leading to the hilarious choice of the worst possible
> solution, which also makes a deeper point that there actually exists no

I really have to say that from False follows...

There is a huge amount of technical problems with heterogeneous
data, but people solving these problems do not submit to
your exclusive definition of "technical". Integration of
information of different kinds of data documents, such as Teletext
and HTML pages, *is* a technical issue. Granted, it is not just
one of electronics.

The major contenders in the office market leverage the data
format problem for economic purposes, worsening the situation
for future generations. And damaging the reputation of XML.
To some extent they have succeeded in undermining the intents
of using XML. For example, one of the contenders simply
provides an isomorphic mapping of .doc to .docx, basically.
That's devilish, and cynic, but silences those who
had really asked for a way to make documents readable (technically
readable) without running the single program capable of reading
.doc and .docx properly.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Thu, 16 Aug 2012 20:31:20 +0200, Georg Bauhaus wrote:

> On 16.08.12 14:56, Dmitry A. Kazakov wrote:
>> On Thu, 16 Aug 2012 13:18:28 +0200, Georg Bauhaus wrote:
>> 
>>> On 16.08.12 09:30, Dmitry A. Kazakov wrote:
>>>> On Wed, 15 Aug 2012 23:29:01 +0200, Georg Bauhaus wrote:
>>>>
>>>>> On 15.08.12 20:53, Dmitry A. Kazakov wrote:
>>>>
>>>>>> And
>>>>>> how these false premises could justify any application of XML even if per
>>>>>> some miracle they happened true?
>>>>>
>>>>> The point of the exercise is to make apparent the variables
>>>>> that help decide when, and when not, to use XML,
>>>>
>>>> List of the variables, please.
>>>
>>> They were given in the text, and even indicated syntactically.
>> 
>> What you listed was unrelated to the issue.
> 
> It was related to the issue from which you keep dragging
> the discussion away: data formats.

So XML is a data format? Let's note that.

>>> I had hoped that someone with a PhD in mathematics would find
>>> this a fair read, even when the subject matter might look strange
>>> at first sight.
>> 
>> If has nothing to do with strangeness. There is a standard procedure of
>> evaluating such things in engineering. You should:
>> 
>> 1. state the problem
> 
> Heterogeneous sources of data. (E.g. Teletext there + XML there)

If sources of data is a problem, then the data format cannot be a solution.
Problems with sources are solved by choosing other sources or other means
applied to the sources.

>> 2. present relevant criteria to evaluate a solution
> 
> Situational, given, as mentioned, e.g. integration of data.

Sources are selected using criteria describing these sources, e.g.
relevance, trustworthiness, independence, accuracy, extent, availability,
QoS, etc.

[ Criteria of choice are always immanent to the thing in question ]

>> 3. present competing solutions > 1 (proving them solving the problem)
> 
> Given. (E.g., what has been done a few times: move from Teletext
> to CSV to XML)

No. Sources of data in a car are sensors. E.g. the lambda sensor:

http://en.wikipedia.org/wiki/Lambda_sensor

>> 4. evaluate these solutions against the criteria
>> 5. make choice based on the ranking obtained

>> We were talking about the network of car devices.
> 
> I was not talking about protocols.

Network peers are communicating using protocols. You have no choice in
selecting the participants of the car's networks. They are defined per
general car design.

>> You seem to imply that fuzzy logic (in its scientific meaning) acts
>> differently from crisp logic by allowing any sorts of non sequitur.
> 
> No. There is a point when switching data formats to something
> general like XML is considered by some programming projects.
> This point is found in [0, 1] ⊂ R. A Yes (1) or No (0) is really
> the consequence of a final preference and this preference's value
> need not be 0 or 1.

It does not make any sense to me, but since it seems irrelevant anyway, be
it so.

>>> and doing so stipulates
>>> that the persons involved can produce weights that work.
>>> Actually, I am sure they have done so many times.
>> 
>> In that case you should summarize/cite their results. You brought the issue
>> of "homogeneity" up as a criterion of choice in favor of XML. Did you?
> 
> On the contrary, I said that XML, if chosen, is a way of
> tackling heterogeneity of data.

What is "heterogeneity of data" and why should it be tackled?

> (E.g., moving away from Teletext
> to XML sent over HTTP.) With Teletext, I have had to find means
> of inspecting a mostly unknown stream of video text data.

Are you talking about "tackling" documents? What sort of documents? The
time diagram of the ignition impulses at the degree angles of the driving
shaft? GPS maps of the navigation system? Traffic rules and regulation?

> Its bits and pieces were partially documented. This was enough
> to write a crude scanner. With XML, I can at just read
> the stuff and see some familiar vocabulary being used. Done.

Nothing is done. Again: What is the problem? What are the solutions?
Positions 1, 2, 3, 4, 5.

I gather the case for car electronics is closed now?

>> So I am merely asking for:
>> 
>> A) the definition of, because yours is absolutely non-standard
> 
> Homogeneity is a pre-network term and means, as mentioned many times,
> of the same kind. (όμοιοϛ and γένοϛ are the parts of the word, TTBOMK.)
> Where "kind" is from a multidimensional space of motivating factors.

What are "motivating factors" of car electronic components, how are they
same?
 
>> B) methodic of its evaluation
> 
> Multivariate analysis of those variables of the programming situation
> that lead to a decision about data formats.

No, the methodic of evaluation a measure of similarity of the "motivating
factors."

>> C) signs of importance for the considered case (car electronics network)
> 
> I said, after establishing background, which see, that "a network
> connecting the electrical devices of a car does not counts
> as heterogeneous." A statement valid against the background only.

No, the importance of similarity/dissimilarity between the "motivating
factors" of/for car electronics.

>> D) comparison to competing solutions
> 
> See above, and everything said so far.

No, you should show that for XML "motivating factors" are more similar or
dissimilar (I have no idea why they should be of any kind and what is the
goal) than the "motivating factors" for, say, the commuter rail schedule.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Thu,  
16 Aug 2012 23:58:00 +0400:

> On Thu, 16 Aug 2012 20:31:20 +0200, Georg Bauhaus wrote:
>
>> On 16.08.12 14:56, Dmitry A. Kazakov wrote:
>>> On Thu, 16 Aug 2012 13:18:28 +0200, Georg Bauhaus wrote:
>>>
>>>> On 16.08.12 09:30, Dmitry A. Kazakov wrote:
>>>>> On Wed, 15 Aug 2012 23:29:01 +0200, Georg Bauhaus wrote:
>>>>>
>>>>>> On 15.08.12 20:53, Dmitry A. Kazakov wrote:
>>>>>

> No, you should show that for XML "motivating factors" are more similar or
> dissimilar (I have no idea why they should be of any kind and what is the
> goal) than the "motivating factors" for, say, the commuter rail schedule.
>

I remember "I'am the walrus" song, with a maniacally sung accent,  
many-many times like Hare-Kṛṣṇa/Kṛṣṇa-Hare.

Sai-baba, btw, had been giving some diamonds... just from a vacuum! its a  
Magic, bro.

--

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 16.08.12 21:58, Dmitry A. Kazakov wrote:

>>> 1. state the problem
>>
>> Heterogeneous sources of data. (E.g. Teletext there + XML there)
> 
> If sources of data is a problem, then the data format cannot be a solution.

OK, that's a different if.

> Problems with sources are solved by choosing other sources or other means
> applied to the sources.

"Problems with the distance Earth:Mars or problems with the temperature
on Mars are solved by choosing others planets or other means applied
to the planets."

No. Problems with sources are actually solved by the sources becoming
different from what they were before. It's a market effect. Customers
make suppliers make different sources.


>>> 2. present relevant criteria to evaluate a solution
>>
>> Situational, given, as mentioned, e.g. integration of data.
> 
> Sources are selected using criteria describing these sources, e.g.
> relevance, trustworthiness, independence, accuracy, extent, availability,
> QoS, etc.
> 
> [ Criteria of choice are always immanent to the thing in question ]

The thing in question is a situation. It is characterized by several
variables. One variable measures the qualities of the data sources.


>>> 3. present competing solutions > 1 (proving them solving the problem)
>>
>> Given. (E.g., what has been done a few times: move from Teletext
>> to CSV to XML)
> 
> No.

Yes. XML can be quite an enhancement when the problem is heterogeneity
of sources. This is how people *have* solved problems of integrating
data. If you cannot present a good reason to sell your data in some
standard form, as a result creating work for others, you're out.

> Sources of data in a car are sensors.

Yes. BTW, even though there are many types of sensors I'm sure,
they all are sensors; depending on distance, then, the observer will place
them on a scale between homogeneous ("Hey, everything is a sensor here!")
and heterogeneous ("Dude. This one works with gas and heat, but that one
uses pressure!")


>>> You seem to imply that fuzzy logic (in its scientific meaning) acts
>>> differently from crisp logic by allowing any sorts of non sequitur.
>>
>> No. There is a point when switching data formats to something
>> general like XML is considered by some programming projects.
>> This point is found in [0, 1] ⊂ R. A Yes (1) or No (0) is really
>> the consequence of a final preference and this preference's value
>> need not be 0 or 1.
> 
> It does not make any sense to me, but since it seems irrelevant anyway, be
> it so.

It is the important bit.  The situation (let me call it
"a programmers' situation", because it is observed from the point of view
of the programmers) is characterized by inputs and outcomes. An outcome
is a decision, in this case, viz whether or not time should be spent on XML.

Some inputs are technical:
- this device has an 8bit wide output port and it spits
13+1 octects and then 2, on request. It does nothing else.
Others are domain specific:
- "We must have something to send to the publisher. They want..."
Others are economical:
- The high speed RDMS style data collection will cost $$$$$$.
Others are "people driven":
- Pointy head boss speaking.
Etc.

These and other variable characteristics of a programmers' situation
all create inputs that find more or less appreciation during the
decision process.
Then, finally, the pointy head boss says "We shoud do XYZ."
Consequently, Choice(XYZ) = 1 as the outcome of the situation,
for everyone,
even when pointy head boss is not fully convinced. He may
privately value Choice(XYZ) at somewhere < 1.



> What is "heterogeneity of data" and why should it be tackled?

Data of different kinds, different along several axes as seen
by the respective "data processors". An algorithm computes results from
several inputs. If "processors" need to process many differences,
if higher order "processors" need many "processor hands" to get
compatible inputs, then this complicates the coordinated processing.
It also costs more time and money.


> Are you talking about "tackling" documents? What sort of documents? The
> time diagram of the ignition impulses at the degree angles of the driving
> shaft? GPS maps of the navigation system? Traffic rules and regulation?

More generally, if an algorithm needs to find information in "documents"
emitted from diverse sources, searching requires assigning meaning
to messages contained therein. The processes of isolating messages
may differ greatly, at several stages of processing.


>> Its bits and pieces were partially documented. This was enough
>> to write a crude scanner. With XML, I can at just read
>> the stuff and see some familiar vocabulary being used. Done.
> 
> Nothing is done.

Compare

....<D5><E9><F6>B.....

to

....<indicator-of-meaning>123.4567</indicator-of-meaning>....


> I gather the case for car electronics is closed now?

From my point of view, we didn't have a case since XML
would not be needed in any way I could imagine (other
that this small customer car info server thingy).


>>> B) methodic of its evaluation
>>
>> Multivariate analysis of those variables of the programming situation
>> that lead to a decision about data formats.
> 
> No, the methodic of evaluation a measure of similarity of the "motivating
> factors."

Methods?
Here are two simple methods that do not always work:
- [all equals] Majority vote.
- [consultation among equals] For each pair (Pi, Pj) of people
who contribute to the decision, two things are of the same kind
if Pi and Pj find them to be of the same kind. If i,j ∈ {1, ..., N},
then let similarity of things be the proportion of agreements
in (N choose 2). The P could be experts from different fields.
(Note: for triples (Pi, Pj, Pk), science has found that
if Pi and Pj agree, but Pk does not, then in most cases Pk
will not uphold disagreement if pressured by Pi and Pj.)
Whether or not Pi and Pj agree might be influenced by unalterable
properties of the things in question if found.

Note in particular that---a priori---there is no way to say
that two things are equal, or similar, or of the same kind before
they have been shown to be, and in which way.
Are the balls of a bearing equal?
Are they homogeneous/heterogeneous? The answer to the latter
question may depend on the identities of the bearings involved,
if you ask a technician, I think, and possibly on who you ask.

For more, and for more realistic function procedures resulting in
decisions, see the description of the programmers' situation above.


>>> D) comparison to competing solutions
>>
>> See above, and everything said so far.
> 
> No, you should show that for XML "motivating factors" are more similar or
> dissimilar

I see. A misunderstanding, I think. Dissimilarity has motivated
preferring, and possibly choosing XML, in order to tackle dissimilarities.

Like heterogeneity has motivated establishing the HOWLG at least
in one way, I think.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Fri, 17 Aug 2012 20:41:10 +0200, Georg Bauhaus wrote:

> On 16.08.12 21:58, Dmitry A. Kazakov wrote:
> 
>>>> 1. state the problem
>>>
>>> Heterogeneous sources of data. (E.g. Teletext there + XML there)
>> 
>> If sources of data is a problem, then the data format cannot be a solution.
> 
> OK, that's a different if.
> 
>> Problems with sources are solved by choosing other sources or other means
>> applied to the sources.
> 
> "Problems with the distance Earth:Mars or problems with the temperature
> on Mars are solved by choosing others planets or other means applied
> to the planets."

Yes, if you wanted to solve these problems, actually. Otherwise, you remind
me our politicians talking about the debt crisis...

> No. Problems with sources are actually solved by the sources becoming
> different from what they were before.

= by changing the source.

>>>> 2. present relevant criteria to evaluate a solution
>>>
>>> Situational, given, as mentioned, e.g. integration of data.
>> 
>> Sources are selected using criteria describing these sources, e.g.
>> relevance, trustworthiness, independence, accuracy, extent, availability,
>> QoS, etc.
>> 
>> [ Criteria of choice are always immanent to the thing in question ]
> 
> The thing in question is a situation.

First it was heterogeneous sources, now it is a situation. Could you state
the problem?

>>>> 3. present competing solutions > 1 (proving them solving the problem)
>>>
>>> Given. (E.g., what has been done a few times: move from Teletext
>>> to CSV to XML)
>> 
>> No.
> 
> Yes. XML can be quite an enhancement when the problem is heterogeneity
> of sources.

No. I repeat, a problem with X is to be solved by doing something with X,
always.

That reminded me the Max Planck's solution:

"A new scientific truth does not triumph by convincing its opponents and
making them see the light, but rather because its opponents eventually die,
and a new generation grows up that is familiar with it."

> This is how people *have* solved problems of integrating
> data.

Data are not integrated. Data are processed. And, as always, you should
explain what does "integration of data" mean, what is the problem with
that, what are the measurable criteria of "integration" and how XML is
better than other "integrators" of data.

>> Sources of data in a car are sensors.
> 
> Yes. BTW, even though there are many types of sensors I'm sure,
> they all are sensors; depending on distance, then, the observer will place
> them on a scale between homogeneous ("Hey, everything is a sensor here!")
> and heterogeneous ("Dude. This one works with gas and heat, but that one
> uses pressure!")

No idea what the above might mean. Sensors of a car use different physical
principles, measure different characteristics of different physical
processes, deploy different materials, are integrated using different
software protocols etc.

>>>> You seem to imply that fuzzy logic (in its scientific meaning) acts
>>>> differently from crisp logic by allowing any sorts of non sequitur.
>>>
>>> No. There is a point when switching data formats to something
>>> general like XML is considered by some programming projects.
>>> This point is found in [0, 1] ⊂ R. A Yes (1) or No (0) is really
>>> the consequence of a final preference and this preference's value
>>> need not be 0 or 1.
>> 
>> It does not make any sense to me, but since it seems irrelevant anyway, be
>> it so.
> 
> It is the important bit.  The situation (let me call it
> "a programmers' situation", because it is observed from the point of view
> of the programmers) is characterized by inputs and outcomes. An outcome
> is a decision, in this case, viz whether or not time should be spent on XML.
> 
> Some inputs are technical:
> - this device has an 8bit wide output port and it spits
> 13+1 octects and then 2, on request. It does nothing else.
> Others are domain specific:
> - "We must have something to send to the publisher. They want..."
> Others are economical:
> - The high speed RDMS style data collection will cost $$$$$$.
> Others are "people driven":
> - Pointy head boss speaking.
> Etc.
> 
> These and other variable characteristics of a programmers' situation
> all create inputs that find more or less appreciation during the
> decision process.
> Then, finally, the pointy head boss says "We shoud do XYZ."
> Consequently, Choice(XYZ) = 1 as the outcome of the situation,
> for everyone,
> even when pointy head boss is not fully convinced. He may
> privately value Choice(XYZ) at somewhere < 1.

Egh, what is the point?

>> What is "heterogeneity of data" and why should it be tackled?
> 
> Data of different kinds, different along several axes as seen
> by the respective "data processors".

Are you talking about datatypes? Yes, there are many. Typed programming
languages rely on the ADT.

XML is supposed to compete in the field of type systems? Seriously?

>> Are you talking about "tackling" documents? What sort of documents? The
>> time diagram of the ignition impulses at the degree angles of the driving
>> shaft? GPS maps of the navigation system? Traffic rules and regulation?
> 
> More generally, if an algorithm needs to find information in "documents"
> emitted from diverse sources, searching requires assigning meaning
> to messages contained therein.

No. Document search does not require assigning meaning nor does it require
messages. What documents? How organized? Where stored? What has XML to do
with all that?

>>> Its bits and pieces were partially documented. This was enough
>>> to write a crude scanner. With XML, I can at just read
>>> the stuff and see some familiar vocabulary being used. Done.
>> 
>> Nothing is done.
> 
> Compare
> 
> ....<D5><E9><F6>B.....
> 
> to
> 
> ....<indicator-of-meaning>123.4567</indicator-of-meaning>....

By which measure?

The first uses the letter 'a' 0 times. The second does it 4 times. Is the
objective to minimize usage of 'A's or to maximize it?

>> I gather the case for car electronics is closed now?
> 
> From my point of view, we didn't have a case since XML
> would not be needed in any way I could imagine (other
> that this small customer car info server thingy).

Finally! 

>>>> B) methodic of its evaluation
>>>
>>> Multivariate analysis of those variables of the programming situation
>>> that lead to a decision about data formats.
>> 
>> No, the methodic of evaluation a measure of similarity of the "motivating
>> factors."
> 
> Methods?
> Here are two simple methods that do not always work:
> - [all equals] Majority vote.
> - [consultation among equals] For each pair (Pi, Pj) of people
[...]

No. What you wrote was a crude description of the multiple-criteria ranking
problem. Before that you need a methodic to measure single criteria
(features), e.g. a "motivating factor." These are done by physical
measurement instruments, expert polls, statistical procedures etc.

>>>> D) comparison to competing solutions
>>>
>>> See above, and everything said so far.
>> 
>> No, you should show that for XML "motivating factors" are more similar or
>> dissimilar
> 
> I see. A misunderstanding, I think. Dissimilarity has motivated
> preferring, and possibly choosing XML, in order to tackle dissimilarities.

Dissimilarity is a *measure*. In a metric vector space the measure of
dissimilarity is the distance between two points. In non-metric spaces
there are various measures of different properties. You evaluate XML
against the commuter rail schedule by measuring the dissimilarity of the
"motivating factors" for both. That will give you, depending on the measure
but considering it in the most simple case numeric, two figures x and y.
You compare x with y and conclude that XML is better than the schedule.
BTW, the difference between the measures must have some "physical" meaning.
E.g. one point of dissimilarity would mean 100 voters, 0.5 kWh, 3.5
drachmas, +4 experience points etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Sat,  
18 Aug 2012 10:24:00 +0400:

>> Compare
>>
>> ....<D5><E9><F6>B.....
>>
>> to
>>
>> ....<indicator-of-meaning>123.4567</indicator-of-meaning>....
>
> By which measure?
>
> The first uses the letter 'a' 0 times. The second does it 4 times. Is the
> objective to minimize usage of 'A's or to maximize it?

Do you know anything about DER/BER encodings?

Dmitry, your salary output is calculated and accounted using XML (soap and  
ofx),
could you root out this plague too?

What do you think about postscript, the same plague? is it protocol or  
configuration?

This looks like "populating evilizm" in a field that you do not know  
clearly, but tend to demonstrate some opposite opinion
without bringing an argument against the subject. Your typical argument is  
always against the expressed
"figuration" of opposite opinion, but not the subject itself.

Returning to M. Plank (is he a programmer, btw?), it is a way of isolation  
 from current state of the art in modern data processing.

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Saturday, August 18, 2012 2:05:36 AM UTC-6, Vasiliy Molostov wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Sat,  
> 18 Aug 2012 10:24:00 +0400:
> 
> What do you think about postscript, the same plague? is it protocol or  
> configuration?
 
Neither. PostScript is a fully functional programming language, albeit specialized for display/printing.

In fact, I believe it to be a better solution than HTML/CSS for layout-specification. (Remember, HTML was *designed* to allow renderers to choose their own layout, virtually all CSS's layout attributes are due to this design decision... and, indeed, produces a practical illustration of what happens when the wrong tools are selected for a particular job [i.e. web-designers trying to get their pages to display the same across platforms are working against a design-decision of HTML].)

Re: Should Inline be private in the private part of a package spec?

[Simon Wright]

Shark8 <onewingedshark@gmail.com> writes:

> Neither. PostScript is a fully functional programming language, albeit
> specialized for display/printing.
>
> In fact, I believe it to be a better solution than HTML/CSS for
> layout-specification. (Remember, HTML was *designed* to allow
> renderers to choose their own layout, virtually all CSS's layout
> attributes are due to this design decision... and, indeed, produces a
> practical illustration of what happens when the wrong tools are
> selected for a particular job [i.e. web-designers trying to get their
> pages to display the same across platforms are working against a
> design-decision of HTML].)

So you propose we should write blogs etc in PostScript?!!!! Count me
out.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Shark8 <onewingedshark@gmail.com> писал(а) в своём письме Sun, 19 Aug 2012  
01:02:07 +0400:

> On Saturday, August 18, 2012 2:05:36 AM UTC-6, Vasiliy Molostov wrote:
>> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме  
>> Sat,
>> 18 Aug 2012 10:24:00 +0400:
>>
>> What do you think about postscript, the same plague? is it protocol or
>> configuration?
> Neither. PostScript is a fully functional programming language, albeit  
> specialized for display/printing.
>
> In fact, I believe it to be a better solution than HTML/CSS for  
> layout-specification. (Remember, HTML was *designed* to allow renderers  
> to choose their own layout, virtually all CSS's layout attributes are  
> due to this design decision... and, indeed, produces a practical  
> illustration of what happens when the wrong tools are selected for a  
> particular job [i.e. web-designers trying to get their pages to display  
> the same across platforms are working against a design-decision of  
> HTML].)

Do you mean that these should be a binary represented,
according to printer or monitor hardware design on which they are  
displayed?

Or these should be portable across?

(xml is also a language, where you can write functions, btw)

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Saturday, August 18, 2012 3:52:27 PM UTC-6, Simon Wright wrote:
> Shark8 <onewingedshark@gmail.com> writes:
> 
> > Neither. PostScript is a fully functional programming language, albeit
> > specialized for display/printing.
> >
> > In fact, I believe it to be a better solution than HTML/CSS for
> > layout-specification. (Remember, HTML was *designed* to allow
> > renderers to choose their own layout, virtually all CSS's layout
> > attributes are due to this design decision... and, indeed, produces a
> > practical illustration of what happens when the wrong tools are
> > selected for a particular job [i.e. web-designers trying to get their
> > pages to display the same across platforms are working against a
> > design-decision of HTML].)
> 
> So you propose we should write blogs etc in PostScript?!!!! Count me
> out.

No, I'm not proposing it as such.
I am saying that HTML/CSS is a workaround due to HTML being used precisly contrary for what it was designed for; but, in addition, most CMSs [blogs, etc] aren't "written in HTML", per se, though they do use it as the "document format" [if you will]. (So little, if any HTML knowledge is actually needed for many CMSs.)

To be more specific: It's stupid to try to use a tool to achieve a goal which is directly opposite of the tool's design-goal. (In HTML it's that HTML *doesn't* specify layout, but instead leaves that to the client.)

Re: Should Inline be private in the private part of a package spec?

[Simon Wright]

Shark8 <onewingedshark@gmail.com> writes:

> To be more specific: It's stupid to try to use a tool to achieve a
> goal which is directly opposite of the tool's design-goal. (In HTML
> it's that HTML *doesn't* specify layout, but instead leaves that to
> the client.)

Now that I can 100% agree with.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 18.08.12 08:24, Dmitry A. Kazakov wrote:
> First it was heterogeneous sources, now it is a situation. Could you state
> the problem?


The problem is to make people produce computer based systems
that produce data in such a way that computer based systems connected
to other computer based systems can process the emitted data well.
Since there is no universal definition of "to process well", participants
in a situation need to define it. One aspect to consider is the amount
of heterogeneity of everything relevant to the respective system.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Mon, 20 Aug 2012 15:51:40 +0200, Georg Bauhaus wrote:

> On 18.08.12 08:24, Dmitry A. Kazakov wrote:
>> First it was heterogeneous sources, now it is a situation. Could you state
>> the problem?
> 
> The problem is to make people produce computer based systems
> that produce data in such a way that computer based systems connected
> to other computer based systems can process the emitted data well.

Now it is a human resource problem or what? Ground a company, hire people,
pay them, maybe they would do something for you, not a technical problem,
so far.

> Since there is no universal definition of "to process well", participants
> in a situation need to define it. One aspect to consider is the amount
> of heterogeneity of everything relevant to the respective system.

The "respective system" is the company you are going to run? Does
"everything relevant" include the shape of paper clips?

Sorry, but diffusing the issue won't help you justify XML, because it
equivalently justifies anything else, e.g. deployment of a bonsai watering
system, looks like an indispensable aspect, doesn't it?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 20.08.12 16:15, Dmitry A. Kazakov wrote:

> Sorry, but diffusing the issue won't help you justify XML,

It is not my intent to justify XML or not.
My intent is simply to say that perceptions like that of
heterogeneity may influence the decision to ask for XML,
and justifiably so.
This has happened, for example in ways you have listed.

Related Example that has been part of this discussion,
and concern compiler configuration files:

A software program to be built comprises, among other things,
four projects.
Three of them are written in Ada, one is written in C++.
Two use GNAT, one uses Janus/Ada, and the fourth uses Visual C++.
Every now and then, the teams need to cooperate to produce one
executable from the libraries that each team will have built.

Let each team need to support three scenarios:
Development, Integration/Testing, Production.

Management says: "Switch to Integration/Testing this afternoon!"

What then happens is that each team changes their tool chain's
setup. Each team does so in a different way, so as to make the
different compilers run as required for Integration/Testing.
Heterogeneity.

Suppose that the entire project does not need any switch mania but
is fine when the respective switches are the same for all units,
and are the equivalents of
 -O -g -gnatwa -gnata
for Integration/Testing.

Switching scenarios is totally mechanical, ready for automatization.
What can be done to make this kind of automatic control of very
different compilers possible?

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Mon,  
20 Aug 2012 20:22:50 +0400:

> On 20.08.12 16:15, Dmitry A. Kazakov wrote:
>
>
> Related Example that has been part of this discussion,
> and concern compiler configuration files:
>
> A software program to be built comprises, among other things,
> four projects.
> Three of them are written in Ada, one is written in C++.
> Two use GNAT, one uses Janus/Ada, and the fourth uses Visual C++.
> Every now and then, the teams need to cooperate to produce one
> executable from the libraries that each team will have built.
>
> Let each team need to support three scenarios:
> Development, Integration/Testing, Production.
>
> Management says: "Switch to Integration/Testing this afternoon!"
>
> What then happens is that each team changes their tool chain's
> setup. Each team does so in a different way, so as to make the
> different compilers run as required for Integration/Testing.
> Heterogeneity.

Excellent example. I doubt that all four will follow some ruling as they  
have different tools and
there is probably no asis in VisualC++.

but the question still open for Janus or GNAT, since a presence of such  
xml access can make tools
like wsdl2aws, aws2wsdl, soap2ada, ada2restful, ada2java, ada2vhdl, etc  
useless, because any developer/tester (even non-ada) can dig xml and write
a generator (namely, xml transform) of any desired kind from a compilation  
result, in the same way it is generated from xmi (uml).

So as for example, this means that VC++ team can receive this compilation  
result in xml and generate from it everything they want.

A tester (even non-ada) can generate a set of tests from this input too  
(even into another language, say based on ajis), with little help from  
real ada developer. This means that Ada developer will think about Ada,  
and a tester would not. It is possible to automate documenting (extracting  
doc from source) without touching these sources, but just from compilation  
result (if it is in xml).this can drastically minimize effort and can  
provide a way to separate job in several pieces, where not well qualified  
personnel (non-ada) can dig these pieces for utility purposes by  
themselves.

But they all still need a compiler.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Mon, 20 Aug 2012 18:22:50 +0200, Georg Bauhaus wrote:

> On 20.08.12 16:15, Dmitry A. Kazakov wrote:
> 
>> Sorry, but diffusing the issue won't help you justify XML,
> 
> It is not my intent to justify XML or not.
> My intent is simply to say that perceptions like that of
> heterogeneity may influence the decision to ask for XML,
> and justifiably so.
> This has happened, for example in ways you have listed.

I don't see how.

> Related Example that has been part of this discussion,
> and concern compiler configuration files:

We have an excellent example how unmanageable Visual Studio became when MS
switched to XML.

I am sure that it also could be demonstrated with all scientific scrutiny
that XML is a poor choice for compiler configuration. As a hint observe
that configuration is no way hierarchical, that as any non-trivial thing it
must have several UIs very different ones and different from the interface
of the compiler itself. That it is non-trivial implies that the
configuration has a *semantics* far beyond dumb string to string mapping
which is all so-called XML "language" can offer.

But you forgot that you once called XML documentation. It became a language
by now? "Moving target?"

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Mon,  
20 Aug 2012 23:28:20 +0400:


>> Related Example that has been part of this discussion,
>> and concern compiler configuration files:
>
> We have an excellent example how unmanageable Visual Studio became when  
> MS
> switched to XML.

It is an MS matters, take a look at eclipse, grails, itelliJ and the rest  
(tremendous amount),
aptana for example even instead of xml uses yaml (which is successfully  
adopted in ruby).

> I am sure that it also could be demonstrated with all scientific scrutiny
> that XML is a poor choice for compiler configuration.

Not a configuration I meant, but an analog of bunch of ALI files in a  
folder, I dont know why you or your opponent refer to configuration.

> As a hint observe
> that configuration is no way hierarchical, that as any non-trivial thing  
> it
> must have several UIs very different ones and different from the  
> interface
> of the compiler itself.

Since it is for automated transform of such data - where do you plan to  
attach a gui? it is a scripting language, like bash.

> That it is non-trivial implies that the
> configuration has a *semantics* far beyond dumb string to string mapping
> which is all so-called XML "language" can offer.

but these (the same) complicated semantics well expressed in xmi (which is  
xml indeed) in any UML related tool -
it is a good place for GUI access and control (already existent), if you  
wish.

> But you forgot that you once called XML documentation. It became a  
> language
> by now? "Moving target?"

XML = eXtensible Markup Language.



-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 20.08.12 21:28, Dmitry A. Kazakov wrote:

>> Related Example that has been part of this discussion,
>> and concern compiler configuration files:
> 
> We have an excellent example how unmanageable Visual Studio became when MS
> switched to XML.

1) For a reason, I have carefully avoided to say "XML".  I have not
given syntax, but I have described a meaningful process involving
different consumers of text documents (configuration files), and have
described a need to transform/adapt a set of specific configuration
instructions for each of the different compilers.

2) But I did explain that "obfuscating companies" like Microsoft are
very good at leveraging misuse of XML (or anything, at that)
for commercial gain, predictably.
The hint given was the 1:1 mapping of .doc to .docx.

Orienting one's arguments along misuses of XML (or anything, for
that matter) like the above has a second order effect on discussions,
a logic that helps turn smart people into irrational anti-XML
instruments:

COMMANDMENT: Microsoft products must *never* have any feature that allows
third parties to do anything not payed to, and controlled by,
Microsoft.

OPPOSING TREND: Customers and administrations ask for more transparency
and control of their own data/documents, produced and stored using
Microsoft products. They try to make XML stand for this.

CONSEQUENCE: Microsoft must produce XML in such a way that (a)
payments to Microsoft are unaffected and (b) so that no third party
gains control.

This consequence is not one attributable to the definition of XML
(or any other way to express the same, for that matter).


> As a hint observe
> that configuration is no way hierarchical,

Hierarchy of configuration or not is totally irrelevant, it may
well be a list of pairs, or simply mentions of configuration items.
Even though the example I have given involves project management and
subordinate teams show hierarchy, it does not matter.
To the hierarchy, the *same* non-hierarchical *intent* is to be
conveyed in some meaningful form or other, calling for
transformation/adaptation of the higher level intent.
So again, non-hierarchy of configuration data is beside the point.

> That it is non-trivial implies that the
> configuration has a *semantics* far beyond dumb string to string mapping
> which is all so-called XML "language" can offer.

Any language that can express "switch to Integration/Testing
this afternoon!" for each of the different compilers will do.
The result will be a suitably transformed/adapted expression
that uses the respective compiler's dumb configuration syntax.

> But you forgot that you once called XML documentation.

(Please, show me where I said documentation. I remember to have
said "data document".)

> It became a language
> by now?

I did not say language either.  I'd rather not use an unqualified
word such as "language". I might say "markup language", implying that
documents become meaningful via ubiquitously implementable
Transformation programs, for example.

Situation now:
Each compiler uses an idiolect for expressing "optimize some".
One cannot use Janus/Ada directives for controlling ObjectAda,
or GNAT, or Visual C++.

Situation then:
Each compiler continues to use an idiolect for expressing
"optimize some", but there exist programs per compiler that allow
management to express "optimize some" so that it is understood
by each of the compilers.

It so happens that these transformation programs need not use, but
can use the combination of ubiquitously available XML and XSLT.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Tue, 21 Aug 2012 13:49:03 +0200, Georg Bauhaus wrote:

> On 20.08.12 21:28, Dmitry A. Kazakov wrote:
> 
>>> Related Example that has been part of this discussion,
>>> and concern compiler configuration files:
>> 
>> We have an excellent example how unmanageable Visual Studio became when MS
>> switched to XML.
> 
> 1) For a reason, I have carefully avoided to say "XML".  I have not
> given syntax, but I have described a meaningful process involving
> different consumers of text documents (configuration files), and have
> described a need to transform/adapt a set of specific configuration
> instructions for each of the different compilers.

Configuration is a file? You should explain why the configuration's
container must be a file, even more why that file must be a text file. But
in any case configuration is never a document.

> 2) But I did explain that "obfuscating companies" like Microsoft are
> very good at leveraging misuse of XML (or anything, at that)
> for commercial gain, predictably.

I see, it is all Microsoft's fault!

Unfortunately no matter how or by whom XML is used it always turns to be a
misuse. When AdaCore does that, and it does this in GPS, it becomes no less
mess than when MS does.

Maybe, there is something wrong with XML itself?

>> But you forgot that you once called XML documentation.
> 
> (Please, show me where I said documentation. I remember to have
> said "data document".)

You said "text document" in very same response. And "data document" is
rubbish, unless means document serving as a data [source/item] for
something or someone.

>> It became a language by now?
> 
> I did not say language either.

That is the problem. You are using intentionally vague language and refuse
to consider practical or formalized cases.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 21.08.12 15:12, Dmitry A. Kazakov wrote:

>> 1) For a reason, I have carefully avoided to say "XML".  I have not
>> given syntax, but I have described a meaningful process involving
>> different consumers of text documents (configuration files), and have
>> described a need to transform/adapt a set of specific configuration
>> instructions for each of the different compilers.
> 
> Configuration is a file?

Please stop putting words in my mouth.

If you think that "configuration files" is rubbish, for any
compiler, tool chain etc, complain to AdaCore:

$ grep -c "configuration file" /opt/GNAT2011/share/doc/gnat/txt/gnat_*.txt
/opt/GNAT2011/share/doc/gnat/txt/gnat_rm.txt:4
/opt/GNAT2011/share/doc/gnat/txt/gnat_ugn.txt:16

Just examples, no definition implied.

> You should explain why the configuration's
> container must be a file,

After you.

What I said was focused on transformations, done by a transformation
program, of meaningful documents expressing "Integration/Testing" into
other meaningful documents expressing "Integration/Testing" in terms
something frequently called configuration files.

I see you don't comment on the all important transformations.

> Unfortunately no matter how or by whom XML is used it always turns to be a
> misuse.

An opinion that is not shared by many not so dumb people,
but OK.


> When AdaCore does that, and it does this in GPS, it becomes no less
> mess than when MS does.

Complain to AdaCore, please, not to me. I can't do anything
about how people use XML.


> Maybe, there is something wrong with XML itself?

So far, I have not read a substantiated argument in this discussion,
about how transformations of XML documents will show what is wrong
with XML. Not even a more general comment about a procedure that
allows integrating runs of different compilers.

>>> But you forgot that you once called XML documentation.
>>
>> (Please, show me where I said documentation. I remember to have
>> said "data document".)
> 
> You said "text document" in very same response.

So no occurrence of "documentation".

> And "data document" is
> rubbish, unless means document serving as a data [source/item] for
> something or someone.

Aha? Data items in a text document, maybe?


>>> It became a language by now?
>>
>> I did not say language either.
> 
> That is the problem. You are ...

No. I am not. Sorry.

> using intentionally vague language and refuse
> to consider practical or formalized cases.

I did. It's just that your examples fell short of saying almost
the same things but by sticking with partial results, I think,
drawing, quite generally, no conclusion.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Tue, 21 Aug 2012 16:17:19 +0200, Georg Bauhaus wrote:

> On 21.08.12 15:12, Dmitry A. Kazakov wrote:

>> Maybe, there is something wrong with XML itself?
> 
> So far, I have not read a substantiated argument in this discussion,
> about how transformations of XML documents will show what is wrong
> with XML. Not even a more general comment about a procedure that
> allows integrating runs of different compilers.

"Transformation of XML documents" does not look like a practical problem to
make substantial arguments about, it looks like a solution for a problem
yet to be stated, of which existence is in question, so far.

>> using intentionally vague language and refuse
>> to consider practical or formalized cases.
> 
> I did. It's just that your examples fell short of saying almost
> the same things but by sticking with partial results, I think,
> drawing, quite generally, no conclusion.

I presented no examples at all. How could I, if XML has no use in my eyes?
It is up to XML proponents to put up cases they think XML might be useful
for. Explain the criteria, show the methodic, compare to competing
solutions.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Pascal Obry]

Dmitry,

> I presented no examples at all. How could I, if XML has no use in my eyes?

I've followed this discussion a bit... No enough time to understand all
your points! All this looks quite silly to me, XML (is a kind of
new/simplified SGML) is a way to make structured information. It is
probably possible to do the same with CSV, or with some other structured
language... Maybe? And what's the point? It is of course possible to
rewrite every Ada code into C, or C++ or whatever...

So what's your problem with XML? Heavy language? Not that much when you
need to define precisely information... I've been working during a long
time into a TI department, so that could explain that... Before XML many
people were defining their own language to store/exchange information.
That was wrong. It was so because SGML was too big, too complex to
handle. XML is a somewhat a good compromise. We may do better, but at
least that's a good current solution to me.

My 2 cents!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 21.08.12 17:06, Dmitry A. Kazakov wrote:
> "Transformation of XML documents" does not look like a practical problem to
> make substantial arguments about, it looks like a solution for a problem
> yet to be stated, of which existence is in question, so far.


Today's computers exchange data using XML documents. They employ
even driven parsers (SAX), and XSL transformations, to good effect;
not usually within a systems (what for?), but between systems.

So what is it that does not exist?

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 21.08.12 17:06, Dmitry A. Kazakov wrote:
> I presented no examples at all.


You have shown a listing that exemplifies a situation
that has, many times, led to the adoption of XML for
the exchange of data.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Tue, 21 Aug 2012 17:29:49 +0200, Pascal Obry wrote:

> Dmitry,
> 
>> I presented no examples at all. How could I, if XML has no use in my eyes?
> 
> I've followed this discussion a bit... No enough time to understand all
> your points! All this looks quite silly to me, XML (is a kind of
> new/simplified SGML) is a way to make structured information. It is
> probably possible to do the same with CSV, or with some other structured
> language... Maybe? And what's the point?

Yes, what is the point?

> So what's your problem with XML? Heavy language? Not that much when you
> need to define precisely information... I've been working during a long
> time into a TI department, so that could explain that... Before XML many
> people were defining their own language to store/exchange information.

How does XML change this? XML is not a language for that purpose. You still
need a layer on top of it in order to represent your information.

> XML is a somewhat a good compromise.

A compromise between what? What was sacrificed in favor of what?

> We may do better, but at
> least that's a good current solution to me.

Of which exactly problem? The problem of exchanging information is
obviously too vague to be true.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Tue, 21 Aug 2012 18:18:32 +0200, Georg Bauhaus wrote:

> On 21.08.12 17:06, Dmitry A. Kazakov wrote:
>> "Transformation of XML documents" does not look like a practical problem to
>> make substantial arguments about, it looks like a solution for a problem
>> yet to be stated, of which existence is in question, so far.
> 
> Today's computers exchange data using XML documents.

So, you are proposing XML for exchanging data between computers? Or is it
just statement that some unlucky computers do it this way? What about
better ways?

> They employ
> even driven parsers (SAX), and XSL transformations, to good effect;
> not usually within a systems (what for?), but between systems.
> 
> So what is it that does not exist?

The problem of transformation XML documents does not exist. I don't see why
data exchange needs that. I don't see why any transformations would be
necessary between systems.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Pascal Obry]

Dmitry,

> The problem of transformation XML documents does not exist. I don't see why
> data exchange needs that. I don't see why any transformations would be
> necessary between systems.

You don't see why because you seem to try hard to deny XML any benefit.
Exchanging structured data is an important point. Before XML we were
using many format and we had to write parsers for all those formats in
every languages. Now with XML (and the corresponding xsd, or wsdl) it is
possible to parse (and *validate*) any data set coming from any
applications.

Maybe you don't like XML, but you just can't say that this is not an
important point. At least the current situation prove you that you are
100% wrong, look around there is XML everywhere.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Vasiliy Molostov" <molostoff@gmail.com> wrote in message 
news:op.wi113hf6ka8ora@aspire.local...
Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Wed, 15 Aug
2012 02:16:10 +0400:

> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message
> news:op.wi0fliuoka8ora@aspire.local...
>> Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Tue, 14

>> about hosts without decent amounts of memory anymore, but redesigning
>> everything to use text files -- which still should never be modified by a
>> human -- and making it a lot slower in the process -- doesn't really make
>> much sense.

>The goal perhaps can be not an efficiency on tiny memory host, but 
>interface to a rich xml toolset that can
>be used by a customer to extract project related data in a manner much 
>simper than asis related stuff. Suppose this xml is a form (subclass)
>of xmi files capable to be read by modern uml modelling tools - ? a 
>customer has an ability to get and control such data
>in a modelling tool directly, whose for now have a bunch of "deployment" 
>abstractions. from some point of view this capability is obvious.

Maybe, but it all sounds like a fantasy to me. (Much about XML sounds like 
pure fantasy to me.)

>And why you have assumed that old code should be removed, you dont like it?

Maintaining two ways to do the same thing is the ultimate in headaches --  
you get to fix all bugs twice. For files not intended for use beyond the 
compilation system, it doesn't make much sense to maintain more than one 
version. (We don't attempt to keep any sort of compatibility on these files 
now between different compiler versions.)

One could imagine having tools to extract information from the project files 
in some other format, but I doubt that we'd change the format a lot. (And 
such tools would require customer demand, obviously.)

                 Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:502bc4df$0$6574$9b4e6d93@newsspool3.arcor-online.net...
> On 15.08.12 13:55, Dmitry A. Kazakov wrote:
...
> A heterogeneous system in this sense is one where a supplier will
> supply data to, say, anything, irrespective of how any one client is
> going to process the data.

Given that I and others are always complaining about Dmitry redefining terms 
to his liking, I have to make the same complaint about this "definition". 
Hetrogeneous systems are those with dissimiliar processing elements, period, 
and there is relevance to how they're related.

What you're describing above is a classic client-server relationship (and 
the subset of that known as service-oriented archtecture). Just one of many 
design patterns, and one that is way over-hyped (it has it's uses, but it 
isn't the answer to every problem).

              Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:502c08f9$0$6573$9b4e6d93@newsspool3.arcor-online.net...
> On 15.08.12 20:53, Dmitry A. Kazakov wrote:
>> And
>> how these [unsubstantiated claim] justify any application of XML even if 
>> per
>> some miracle they happened true?
>
> I'll answer in another post, but here is a business idea
> involving cars, XML, and smart phones.
...
> Technically, then, have the car have a small web server
> (perhaps smaller than AWS), and have the server send an XML
> document to the owner's mobile phone. Have that triggered
> by web  requests. Add information in caches as necessary.

Sure sounds wildly complicated, when all that is needed is to send 
appropriate HTML pages to the phone's browser. HTML is easy to create by a 
program (just as easy as XML, as they're related after all). It might make 
sense to use XML to send data to an app, but that's clearly the hard way to 
do things.

                                Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:5033ff28$0$6185$ba4acef3@reader.news.orange.fr...
...
> Maybe you don't like XML, but you just can't say that this is not an
> important point. At least the current situation prove you that you are
> 100% wrong, look around there is XML everywhere.

...which is probably why "modern" computing is unmitigated rubbish. Hardly 
anything that has happened since the 1990s is an improvement - most of it is 
dubious eye candy while simulateously providing multiple new ways to lose 
your identity and ultimately freedom. Bah humbug.

                                          Randy.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Randy Brukardt <randy@rrsoftware.com> писал(а) в своём письме Wed, 22 Aug  
2012 03:11:46 +0400:

> ...which is probably why "modern" computing is unmitigated rubbish.  
> Hardly
> anything that has happened since the 1990s is an improvement - most of  
> it is
> dubious eye candy while simulateously providing multiple new ways to lose
> your identity and ultimately freedom. Bah humbug.
>
>                                           Randy.

:)

The result is more important than identity, and I sure that this one (an  
identity) is not correlated with these utility things.

And some utility things are standard ones (ISO_20022 for example) for now.

Ada in old days had the same face for hard c/c++ people, btw.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Shark8]

On Tuesday, August 21, 2012 3:35:35 PM UTC-6, Pascal Obry wrote:
> Dmitry,
> 
> 
> > The problem of transformation XML documents does not exist. I don't see why
> > data exchange needs that. I don't see why any transformations would be
> > necessary between systems.
> 
> 
> You don't see why because you seem to try hard to deny XML any benefit.
> Exchanging structured data is an important point. 

Even so, not all data may be particularly well-suited to XML; not all things are heirachial in nature and it seems to me to be a mistake to assume such a main-point is the best for everything.

That is why, IMO, some [many?] new CS people are confused about subtypes; they've been led to think that extension is the right way of going about things via OOP.

> Before XML we were
> using many format and we had to write parsers for all those formats in
> every languages. Now with XML (and the corresponding xsd, or wsdl) it is
> possible to parse (and *validate*) any data set coming from any
> applications.

So? Why should everything be crammed into XML?
INI-files are excelent for storing configuration data that is easily accessable to the user.
CSV-files are excellent in regard to transmitting a single spreadsheet. {The XML *may* be large/cumbersome in the spreadsheet case.}


> Maybe you don't like XML, but you just can't say that this is not an
> important point. At least the current situation prove you that you are
> 100% wrong, look around there is XML everywhere.

Just because it's everywhere doesn't mean that it's a good tool for addressing the given problem: look at C++, it's everywhere but isn't condusive toward writing stable softwhere in and of itself.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Randy Brukardt <randy@rrsoftware.com> писал(а) в своём письме Wed, 22 Aug  
2012 02:31:22 +0400:

>
> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message
> news:op.wi113hf6ka8ora@aspire.local...
> Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Wed, 15 Aug
> 2012 02:16:10 +0400:

> Maybe, but it all sounds like a fantasy to me. (Much about XML sounds  
> like
> pure fantasy to me.)

Yep, like tasking in '80-90. It was a pure fantasy. But useful.

> Maintaining two ways to do the same thing is the ultimate in headaches --
> you get to fix all bugs twice. For files not intended for use beyond the
> compilation system, it doesn't make much sense to maintain more than one
> version. (We don't attempt to keep any sort of compatibility on these  
> files
> now between different compiler versions.)

No, as I see it that new thing can be on top of already existing one, and  
this looks like an extension only, a king of.

> One could imagine having tools to extract information from the project  
> files
> in some other format, but I doubt that we'd change the format a lot. (And
> such tools would require customer demand, obviously.)

This is one of the ways to attract more customers and minimize effort for  
existing ones.
A file can be just another one, does not matter.

Re: Should Inline be private in the private part of a package spec?

[Pascal Obry]

Le 22/08/2012 01:54, Shark8 a �crit :
> So? Why should everything be crammed into XML?

Can you quote where I did say everything?

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Tue, 21 Aug 2012 23:35:35 +0200, Pascal Obry wrote:

> Dmitry,
> 
>> The problem of transformation XML documents does not exist. I don't see why
>> data exchange needs that. I don't see why any transformations would be
>> necessary between systems.
> 
> You don't see why because you seem to try hard to deny XML any benefit.

It is not a hard try. Yes, I have an opinion on XML because in my job
(automation systems and embedded) XML became a real plague. I asked others
to put up a practical case where XML might be useful, technically useful,
rather than per popularity vote or legacy. Nobody proposed any.

> Exchanging structured data is an important point.

It is an important problem, yes, but XML is poor for that. XML

1. is extremely inefficient
2. fails to capture the structure (e.g. recursive, interlinked structures)
3. lacks even basic data types (everything is string, not even weakly
typed)
4. lacks any means to describe the semantics (e.g. no ADT),
5. incapable to validate data (because of 4)
6. requires complex, resource consuming, vulnerable infrastructure like
parsers
7. is not redundant and at the same time absolutely permissive (requires
complex validation of itself)

> Before XML we were
> using many format and we had to write parsers for all those formats in
> every languages. Now with XML (and the corresponding xsd, or wsdl) it is
> possible to parse (and *validate*) any data set coming from any
> applications.

And it is still so with XML, because XML considered for data exchange is
not of the application level. It is just a very ugly and unsafe
transport/presentation level protocol. The application level is still to
develop and XML is no relief, it just complicates things. As for
transport/presentation there is little need in any parsing at all.

So, again, taking the data exchange issue, what is the particular
[sub]problem XML solves?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 22.08.12 00:46, Randy Brukardt wrote:
> "Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
> news:502c08f9$0$6573$9b4e6d93@newsspool3.arcor-online.net...
>> On 15.08.12 20:53, Dmitry A. Kazakov wrote:
>>> And
>>> how these [unsubstantiated claim] justify any application of XML even if 
>>> per
>>> some miracle they happened true?
>>
>> I'll answer in another post, but here is a business idea
>> involving cars, XML, and smart phones.
> ...
>> Technically, then, have the car have a small web server
>> (perhaps smaller than AWS), and have the server send an XML
>> document to the owner's mobile phone. Have that triggered
>> by web  requests. Add information in caches as necessary.
> 
> Sure sounds wildly complicated, when all that is needed is to send 
> appropriate HTML pages to the phone's browser.

In real life situations (meaning that layout matters) XML turns
out to be easier, and much more practical:

Zeroth, a setup that sends plain HTML does not meet the usual
requirements for presenting information to end users (excluding
engineers who would be happy just seeing some text).

First, HTML is inflexible in that you cannot choose a natural
vocabulary for car information.

Second, separation of teams: providing car status information
is very different from presenting car information. There are
providers, and there are presenters.

Third, you need to vary output of the server for different kinds
of recipient devices. For shared cars in particular, and for
quickly changing devices, too. The necessary flexibility is not
easily handled if a server is built into a car and emits HTML,
CSS and Javascript.  Note that the car does not change, so the
information provided by its web server does not change, but
the devices do. (Would you want the car's web server to be
updated every time one of the car's users connects a new,
different device?)

Choosing XML addresses these issues, since the car's web server
can be left alone when clients should change.

> It might make 
> sense to use XML to send data to an app, but that's clearly the hard way to 
> do things.

It seems the easiest, even in comparison to HTML, in that---for the
service in question---everything needed to handle XML is in place,
including transformation machinery.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Wed,  
22 Aug 2012 16:49:35 +0400:

> It seems the easiest, even in comparison to HTML, in that---for the
> service in question---everything needed to handle XML is in place,
> including transformation machinery.

While you are right here, It is very important to address to the fact that  
every modern
browser (even in phone) does such transformations on-the-fly (aka xslt  
transforms),
this means that html in car server-side is useless and even scrape and  
dirty thing,
while xml gives only relevant data to be transformed into readable thing  
by client-side machinery.

I suppose that not all readers of this topic can look at this fact  
properly, but probably
tend to see it as a mess with all these "visual" CSS and javascript nicery  
embedded just
inside into a hardware sensor.

Regarding to project/compilation data produced by compiler in xml form,
the above means that it is possible to read such data just having
only any modern html browser, which will make done such transformations  
into desired readable form.
For example it is what adabrowse tool does, indeed.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 22.08.12 09:32, Dmitry A. Kazakov wrote:
> On Tue, 21 Aug 2012 23:35:35 +0200, Pascal Obry wrote:
> 
>> Dmitry,
>>
>>> The problem of transformation XML documents does not exist. I don't see why
>>> data exchange needs that. I don't see why any transformations would be
>>> necessary between systems.
>>
>> You don't see why because you seem to try hard to deny XML any benefit.
> 
> It is not a hard try. Yes, I have an opinion on XML because in my job
> (automation systems and embedded) XML became a real plague. I asked others
> to put up a practical case where XML might be useful, technically useful,
> rather than per popularity vote or legacy. Nobody proposed any.
> 
>> Exchanging structured data is an important point.
> 
> It is an important problem, yes, but XML is poor for that. XML
> 
> 1. is extremely inefficient

As always, the question is inefficient for what and for whom.

As has been repeated a few times now, there are systems where many
would agree that there is no point in using XML or even CSV or something.

For yet another example of a practical case in favor of XML,
consider a program that needs to retrieve information. A set
of sources is external. The program needs to input

(a) Microsoft Excel files produced by different people
    using different versions of the software.
(b) PDF files
(c) plain text files
(d) HTML files
(e) etc.

The program may not be able to change its sources, as the market may
or may not exert influence on the producers of the sources, since they
may or may not see economic advantage in switching from sending
Excel files to XML documents that use the tagging vocabulary of
some industry standard.

In a multicompany project the situation might be better because
parties may agree to use some common "carrier format" such as XML,
or something completely different. This agreement still lets all
companies live behind the walls they prefer.


> 2. fails to capture the structure (e.g. recursive, interlinked structures)

?

> 3. lacks even basic data types (everything is string, not even weakly
> typed)

?

> 4. lacks any means to describe the semantics (e.g. no ADT),

Yes, as this capability was not intended for XML proper. However,
if you use something like (like!) WSDL, there is an unambiguous way
to transform an ADT into the preferred programming language.

> 5. incapable to validate data (because of 4)

OK, "XML validation" /= "type checking of a compiler".


> 6. requires complex, resource consuming, vulnerable infrastructure like
> parsers

Yes, there are cases where such parsers are needed, and even more
of such things. For example, if you run Google.

> 7. is not redundant and at the same time absolutely permissive (requires
> complex validation of itself)

Another set of unqualified word ({"redundant", ... })

>> Before XML we were
>> using many format and we had to write parsers for all those formats in
>> every languages. Now with XML (and the corresponding xsd, or wsdl) it is
>> possible to parse (and *validate*) any data set coming from any
>> applications.
> 
> And it is still so with XML, because XML considered for data exchange is
> not of the application level.

You don't have to write parser infrastructure when you
can use XML.

> It is just a very ugly

What does "ugly" mean, technically?

> and unsafe

Another claim. XML may have been called robust (in that the
brackets are named, e.g., not overloaded). Has it ever been
called safe?


> The application level is still to
> develop and XML is no relief, it just complicates things.

A problem that XML-based setups solve is when they greatly
simplify the combinatorial explosion of some ad-hoc variety
of mutually semi-compatible ways of exchanging data.
Turning data into application level objects is easier,
standards-driven, and more regular, in the same sense that
any other standard way of exchanging data would achieve
this.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Wed, 22 Aug 2012 15:12:41 +0200, Georg Bauhaus wrote:

> On 22.08.12 09:32, Dmitry A. Kazakov wrote:
>> On Tue, 21 Aug 2012 23:35:35 +0200, Pascal Obry wrote:
>> 
>>> Dmitry,
>>>
>>>> The problem of transformation XML documents does not exist. I don't see why
>>>> data exchange needs that. I don't see why any transformations would be
>>>> necessary between systems.
>>>
>>> You don't see why because you seem to try hard to deny XML any benefit.
>> 
>> It is not a hard try. Yes, I have an opinion on XML because in my job
>> (automation systems and embedded) XML became a real plague. I asked others
>> to put up a practical case where XML might be useful, technically useful,
>> rather than per popularity vote or legacy. Nobody proposed any.
>> 
>>> Exchanging structured data is an important point.
>> 
>> It is an important problem, yes, but XML is poor for that. XML
>> 
>> 1. is extremely inefficient
> 
> As always, the question is inefficient for what and for whom.

For the network and the peers. The measures for both can be easily
provided.

>> 2. fails to capture the structure (e.g. recursive, interlinked structures)
> 
> ?

Take Containers.Doubly_Linked_Lists as an example. The closure object of a
list is the structure in question.

>> 3. lacks even basic data types (everything is string, not even weakly
>> typed)
> 
> ?

Compare XML to Ada or C. The latter languages have elementary data types
which can be used in algebraic operations constructing new types.

>> 6. requires complex, resource consuming, vulnerable infrastructure like
>> parsers
> 
> Yes, there are cases where such parsers are needed, and even more
> of such things. For example, if you run Google.

Remember that the case in question is "exchanging structured data," not
running Google.
 
>> 7. is not redundant and at the same time absolutely permissive (requires
>> complex validation of itself)
> 
> Another set of unqualified word ({"redundant", ... })

http://en.wikipedia.org/wiki/Redundancy_%28engineering%29

You could argue that redundancy is not required for a layer running over a
safe transmission channel, but then what is the purpose of the abundance of
XML's syntactic excesses? You cannot have both.

>>> Before XML we were
>>> using many format and we had to write parsers for all those formats in
>>> every languages. Now with XML (and the corresponding xsd, or wsdl) it is
>>> possible to parse (and *validate*) any data set coming from any
>>> applications.
>> 
>> And it is still so with XML, because XML considered for data exchange is
>> not of the application level.
> 
> You don't have to write parser infrastructure when you
> can use XML.

1. I don't need parser if I don't use XML.

2. I need to write the application layer serializing and deserializing
object in any case.

3. Serialization is much simpler without XML. See Ada.Streams.

>> It is just a very ugly
> 
> What does "ugly" mean, technically?

Technically ugly means inefficient.

>> and unsafe
> 
> Another claim. XML may have been called robust (in that the
> brackets are named, e.g., not overloaded). Has it ever been
> called safe?

Safety could be against

1. intentional misuse

2. unintentional errors

>> The application level is still to
>> develop and XML is no relief, it just complicates things.
> 
> A problem that XML-based setups solve is when they greatly
> simplify the combinatorial explosion of some ad-hoc variety
> of mutually semi-compatible ways of exchanging data.

Huh, XML indeed simplifies combinatorial explosion in many possible
meanings of this word. There is a multitudes of XML representations,
equivalent or almost equivalent variants which make versioning and
validation difficult, at best. There is a multitude of XML tools to buy, to
validate, to train personnel, to maintain, to scrape. There is a multitude
of network traffic, disk space, CPU time lost due to XML. Most of mentioned
is more than O(n). Some could be O(exp n). So, yes, combinatorial
explosion, shit hitting the fan...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 22.08.12 16:30, Dmitry A. Kazakov wrote:

>> As always, the question is inefficient for what and for whom.
> 
> For the network and the peers. The measures for both can be easily
> provided.

Well, that would depend on the specifics of "network" and its mode
of use, wouldn't it?

>>> 2. fails to capture the structure (e.g. recursive, interlinked structures)
>>
>> ?
> 
> Take Containers.Doubly_Linked_Lists as an example. The closure object of a
> list is the structure in question.

"closure object" = ?

<l>
 <it id = "one"           f="two" />
 <it id = "two"   b="one" f="three" />
 <it id = "three" b="two" />
</l>

>>> 3. lacks even basic data types (everything is string, not even weakly
>>> typed)
>>
>> ?
> 
> Compare XML to Ada or C. The latter languages have elementary data types
> which can be used in algebraic operations constructing new types.

Many type definitions will be possible using the respective part of XML
technology (XSD, or Relax NG with suitable choices). If one wishes to
use them. This does not yield Ada data types, but it does yield data
with loads of information about the types, including Ada style range
constraints. Reuse of types in other types is possible.

But I would not want all those types, because my interpretation
of data might be justifiably different.

>>> 6. requires complex, resource consuming, vulnerable infrastructure like
>>> parsers
>>
>> Yes, there are cases where such parsers are needed, and even more
>> of such things. For example, if you run Google.
> 
> Remember that the case in question is "exchanging structured data," not
> running Google.

Google is the biggest thing on earth that exchanges data with
just about everything outside microwave ovens.

>>> 7. is not redundant and at the same time absolutely permissive (requires
>>> complex validation of itself)
>>
>> Another set of unqualified word ({"redundant", ... })
> 
> http://en.wikipedia.org/wiki/Redundancy_%28engineering%29

(That's still unqualified, but as you say, redundancy may refer
to layers. But there is more.)

The purpose of "syntactic excess" of XML is about the same as in Ada:
put a left bracket at the start of a thing, and put a right bracket
at the end of a thing, possibly named:

  title: begin ... end title;
  package Foo is  ... end Foo;


  <title>...</title>
  <div id="Foo"> ... </div>

Unlike HTML, and like Ada, XML allows for some redundancy by making
sure that for each left bracket there is a right bracket in the text.
Most right brackets in XML tend to be named brackets, just like in Ada.
Both are unlike Ada's streamed data.


>> You don't have to write parser infrastructure when you
>> can use XML.
> 
> 1. I don't need parser if I don't use XML.

I need to write many parsers if I can't use XML. I use data not
generated by our programs.

> 2. I need to write the application layer serializing and deserializing
> object in any case.

OK.

> 3. Serialization is much simpler without XML. See Ada.Streams.

Is Ada's serialization easier for you, the 1 writer, or easier for
the N unknown readers out there who might not be using Ada?



> Safety could be against
> 
> 1. intentional misuse

I don't see how any source of data could protect against misuse of data
once data have left the "building".

> 2. unintentional errors

?


[rant about more than one standards-conforming implementation
of XML tools.]

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Wed, 22 Aug 2012 18:48:03 +0200, Georg Bauhaus wrote:

> On 22.08.12 16:30, Dmitry A. Kazakov wrote:
> 
>>> As always, the question is inefficient for what and for whom.
>> 
>> For the network and the peers. The measures for both can be easily
>> provided.
> 
> Well, that would depend on the specifics of "network" and its mode
> of use, wouldn't it?

There exist pretty general measures, e.g. number of bits, FLOPs, QoS and so
on.

>>>> 2. fails to capture the structure (e.g. recursive, interlinked structures)
>>>
>>> ?
>> 
>> Take Containers.Doubly_Linked_Lists as an example. The closure object of a
>> list is the structure in question.
> 
> "closure object" = ?

Linked list is not an object. An object could be a closure of the list upon
the relation predecessor-successor, e.g. a set of linked nodes.
 
> <l>
>  <it id = "one"           f="two" />
>  <it id = "two"   b="one" f="three" />
>  <it id = "three" b="two" />
> </l>

Which speaks for itself.

>>>> 6. requires complex, resource consuming, vulnerable infrastructure like
>>>> parsers
>>>
>>> Yes, there are cases where such parsers are needed, and even more
>>> of such things. For example, if you run Google.
>> 
>> Remember that the case in question is "exchanging structured data," not
>> running Google.
> 
> Google is the biggest thing on earth that exchanges data with
> just about everything outside microwave ovens.

This is why XML would not require complex, resource consuming, vulnerable
parsers?

>>>> 7. is not redundant and at the same time absolutely permissive (requires
>>>> complex validation of itself)
>>>
>>> Another set of unqualified word ({"redundant", ... })
>> 
>> http://en.wikipedia.org/wiki/Redundancy_%28engineering%29
> 
> (That's still unqualified, but as you say, redundancy may refer
> to layers. But there is more.)
> 
> The purpose of "syntactic excess" of XML is about the same as in Ada:

Not at all. Ada's redundancy is here to reduce influence of certain class
of programming errors. Ada is not proposed for exchanging structured data
between computers. Ada is a programming language. XML in this context plays
the role of a protocol to exchange above mentioned data. The nature of
errors which may appear upon such data exchange, their behavior has close
to nothing in common to the typo errors programmers do when they write Ada
code.

If you want to promote XML to a programming language that would be a
different beast, though no less ugly one.

>>> You don't have to write parser infrastructure when you
>>> can use XML.
>> 
>> 1. I don't need parser if I don't use XML.
> 
> I need to write many parsers if I can't use XML. I use data not
> generated by our programs.

In that case this is irrelevant to the issue. Other programs use formats
they do. If that requires parsing that is their problem. Two wrongs do not
make one right.

>> 3. Serialization is much simpler without XML. See Ada.Streams.
> 
> Is Ada's serialization easier for you, the 1 writer, or easier for
> the N unknown readers out there who might not be using Ada?

It is irrelevant whether they use Ada. Relevant is the architecture of the
protocol. A protocol similar to one of Ada streams deploy does not need
parsing.

>> Safety could be against
>> 
>> 1. intentional misuse
> 
> I don't see how any source of data could protect against misuse of data
> once data have left the "building".

http://en.wikipedia.org/wiki/Digital_signature

>> 2. unintentional errors
> 
> ?

E.g. typo errors. Baiting, when you type some garbage to let the compiler
to make a suggestion etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 22.08.12 19:44, Dmitry A. Kazakov wrote:
>> I need to write many parsers if I can't use XML. I use data not
>> >generated by our programs.
> In that case this is irrelevant to the issue. Other programs use formats
> they do. If that requires parsing that is their problem.

Next time I download a PDF from A Big Bank or from a corporation,
destined to be a PDF document, I'll tell them that it is their
problem if I need to parse it.

Next time I download a freely available entry from a financial
or technical blog of not so strictly conforming quality, I tell
them it's their problem if I need to parse this.

Good joke.
Not sure what they do when I tell them. Whether they will just
laugh their heads off or stare in utter astonishment at such
a weirdo appearance.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Wed, 22 Aug 2012 21:59:36 +0200, Georg Bauhaus wrote:

> On 22.08.12 19:44, Dmitry A. Kazakov wrote:
>>> I need to write many parsers if I can't use XML. I use data not
>>> >generated by our programs.
>> In that case this is irrelevant to the issue. Other programs use formats
>> they do. If that requires parsing that is their problem.
> 
> Next time I download a PDF from A Big Bank or from a corporation,
> destined to be a PDF document, I'll tell them that it is their
> problem if I need to parse it.

Do you know a way to process PDF documents without parsing them? Then, do
it!

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 22 Aug 2012 21:59:36 +0200, Georg Bauhaus wrote:
> 
>> On 22.08.12 19:44, Dmitry A. Kazakov wrote:
>>>> I need to write many parsers if I can't use XML. I use data not
>>>>> generated by our programs.
>>> In that case this is irrelevant to the issue. Other programs use formats
>>> they do. If that requires parsing that is their problem.
>> 
>> Next time I download a PDF from A Big Bank or from a corporation,
>> destined to be a PDF document, I'll tell them that it is their
>> problem if I need to parse it.
> 
> Do you know a way to process PDF documents without parsing them? Then, do
> it!

How is my parsing their problem?
If they did use XML then my life would be easier.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 22.08.12 19:44, Dmitry A. Kazakov wrote:
> On Wed, 22 Aug 2012 18:48:03 +0200, Georg Bauhaus wrote:
>
>> On 22.08.12 16:30, Dmitry A. Kazakov wrote:
>>
>>>> As always, the question is inefficient for what and for whom.
>>>
>>> For the network and the peers. The measures for both can be easily
>>> provided.
>>
>> Well, that would depend on the specifics of "network" and its mode
>> of use, wouldn't it?
>
> There exist pretty general measures, e.g. number of bits, FLOPs, QoS and so
> on.

In the set called "and so on", information retrieval programs will
be efficient at all once they can interpret a data item to be an object
for which FLOPs make any sense. That's easier to see when there is
markup than when the program needs to guess if some four octets
could be a float.

>>>>> 2. fails to capture the structure (e.g. recursive, interlinked structures)
>>>>
>>>> ?
>>>
>>> Take Containers.Doubly_Linked_Lists as an example. The closure object of a
>>> list is the structure in question.
>>
>> "closure object" = ?
>
> Linked list is not an object. An object could be a closure of the list upon
> the relation predecessor-successor, e.g. a set of linked nodes.

So the closure could be mapped to ... what if not an object?

>> <l>
>>   <it id = "one"           f="two" />
>>   <it id = "two"   b="one" f="three" />
>>   <it id = "three" b="two" />
>> </l>
>
> Which speaks for itself.

Indeed, it shows that you can have the kind of structures you wanted;
I'll gladly add recursive structure � la Ada; for now,

   l'(it'(id => one, f => two, others => <>),
      it'(id => two, f => three, b => one),
      it'(id => three, b => two, others => <>);

Stream this aggregate to a C++ program outside your project ...


>>>>> 6. requires complex, resource consuming, vulnerable infrastructure like
>>>>> parsers
>>>>
>>>> Yes, there are cases where such parsers are needed, and even more
>>>> of such things. For example, if you run Google.
>>>
>>> Remember that the case in question is "exchanging structured data," not
>>> running Google.
>>
>> Google is the biggest thing on earth that exchanges data with
>> just about everything outside microwave ovens.
>
> This is why XML would not require complex, resource consuming, vulnerable
> parsers?

XML will not require complex, resource consuming, vulnerable parsers
once applications need not input non-XML data, such as Excel files
or HTML pages.


>> The purpose of "syntactic excess" of XML is about the same as in Ada:
>
> Not at all. Ada's redundancy is here to reduce influence of certain class
> of programming errors.

For example, Ada has named brackets in place of overloaded brackets
in many places. Like XML.

> Ada is not proposed for exchanging structured data
> between computers.

It is, however, required to say how to exchange structured program
source text between compilers.

> Ada is a programming language. XML in this context plays
> the role of a protocol to exchange above mentioned data.

No. It is a markup language for tagging data in text documents.
We have been here before.

> The nature of
> errors which may appear upon such data exchange, their behavior has close
> to nothing in common to the typo errors programmers do when they write Ada
> code.

When programmers correct errors that the compilers have found,
some of the are strictly syntax errors, others are of a more
grammatical nature. Source text not being a stream of octets
makes correcting Ada source text easier. Similarly for XML.


>>>> You don't have to write parser infrastructure when you
>>>> can use XML.
>>>
>>> 1. I don't need parser if I don't use XML.
>>
>> I need to write many parsers if I can't use XML. I use data not
>> generated by our programs.
>
> In that case this is irrelevant to the issue.

Irrelevant to your issue, I guess, of exchanging data in a network
where all components know what's required to participate. The issues
other people face have to do with mutual, deliberate lack of information,
and with non-coordination. If inscrutable serializing is added on
top of that, parties end up with trial and error. That's a lot less so
when they at least use  XML.


> A protocol similar to one of Ada streams deploy does not need
> parsing.

An exchange of data using streams does not work without agreements
on the stream's content; streams from 'Write are not usually
self-documenting. That's a lot less so with XML, therefore XML
is a suitable choice in situations without agreements.


>>> Safety could be against
>>>
>>> 1. intentional misuse
>>
>> I don't see how any source of data could protect against misuse of data
>> once data have left the "building".
>
> http://en.wikipedia.org/wiki/Digital_signature

Party A   1 <----> *   Party B

Party A provides data together with a signature.
The signature says that what was sent was really sent by A.
How does a signature prevent misusing what was sent?
(How can a signed kitchen knife prevent its use as a weapon?)
The recipient does not learn anything except that the origin is A.
The recipient cannot validate the structure using a signature.
The recipient is free to use information in ways not foreseen.

No accessible piece of data in whichever shape of form can
be protected from being used in any way.

Being able to interpret data is a consequence of assigning
meaning to its parts. A and B may have differing views on that.

There are networks without an arbiter. Then, if things work for
both A and B, then they are both right.


>>> 2. unintentional errors
>>
>> ?
>
> E.g. typo errors. Baiting, when you type some garbage to let the compiler
> to make a suggestion etc.

XML does not only provide for error recovery, as do other ways of
exchanging data. (E.g. through bracket naming, or through a
redundant amount of syntax; some markup is redundant in that an
SGML/XML processor could infer it without running into ambiguity).
It can also have good effects on producers of XML insofar as they can
employ ubiquitous tools to make sure they are really producing
XML documents.

Many do.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Vasiliy Molostov" <molostoff@gmail.com> wrote in message 
news:op.wjezxbvkka8ora@aspire.local...
Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Wed, 22 Aug
2012 03:11:46 +0400:

>> ...which is probably why "modern" computing is unmitigated rubbish. 
>> Hardly
>> anything that has happened since the 1990s is an improvement - most of 
>> it is
>> dubious eye candy while simulateously providing multiple new ways to lose
>> your identity and ultimately freedom. Bah humbug.
>>
>>                                           Randy.
>
>:)
>
>The result is more important than identity, and I sure that this one (an 
>identity) is not correlated with these utility things.

I'd like to respond to this, but I can't figure out what it means. I was 
talking about the fact that behind all of that eye candy are systems that 
designed to invade your privacy and lose your identity (that is, identity 
theft), and the inevitable reaction to it is going to remove the last chance 
at any freedom. Prepare to be enslaved!

>And some utility things are standard ones (ISO_20022 for example) for now.

What utilities have to do with eye candy, privacy, and freedom, beyond my 
ability to figure out.

>Ada in old days had the same face for hard c/c++ people, btw.

Face? We're talking about facts, not "faces". If the facts were different, 
the conclusion would be different. I can certainly see reasons why people 
might want to use XML in program-to-program communication, but it only makes 
sense when the programs are created by different entities. (And I've never 
believed in that as a successful model of anything.)

                                   Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:5034d558$0$6581$9b4e6d93@newsspool3.arcor-online.net...
> On 22.08.12 00:46, Randy Brukardt wrote:
>> "Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message
>> news:502c08f9$0$6573$9b4e6d93@newsspool3.arcor-online.net...
>>> On 15.08.12 20:53, Dmitry A. Kazakov wrote:
>>>> And
>>>> how these [unsubstantiated claim] justify any application of XML even 
>>>> if
>>>> per
>>>> some miracle they happened true?
>>>
>>> I'll answer in another post, but here is a business idea
>>> involving cars, XML, and smart phones.
>> ...
>>> Technically, then, have the car have a small web server
>>> (perhaps smaller than AWS), and have the server send an XML
>>> document to the owner's mobile phone. Have that triggered
>>> by web  requests. Add information in caches as necessary.
>>
>> Sure sounds wildly complicated, when all that is needed is to send
>> appropriate HTML pages to the phone's browser.
>
> In real life situations (meaning that layout matters) XML turns
> out to be easier, and much more practical:
>
> Zeroth, a setup that sends plain HTML does not meet the usual
> requirements for presenting information to end users (excluding
> engineers who would be happy just seeing some text).

Baloney.

> First, HTML is inflexible in that you cannot choose a natural
> vocabulary for car information.

Who gives a f*** about a "vocabulary"? We're talking about presenting 
information to a browser in a human-readable form. That's the problem *you* 
set up.

> Second, separation of teams: providing car status information
> is very different from presenting car information. There are
> providers, and there are presenters.

Surely the software will be structured that way, but unless you plan to send 
your browser unformatted information and hope that it can do something 
useful with it, you also have to send a presenter along with it. (As I said 
previously, this all changes if you are sending the information to an app 
rather than a browser. But that's NOT the problem you set up.)

> Third, you need to vary output of the server for different kinds
> of recipient devices. For shared cars in particular, and for
> quickly changing devices, too. The necessary flexibility is not
> easily handled if a server is built into a car and emits HTML,
> CSS and Javascript.  Note that the car does not change, so the
> information provided by its web server does not change, but
> the devices do. (Would you want the car's web server to be
> updated every time one of the car's users connects a new,
> different device?)

Apparently, you have completely forgotten the original purpose of HTML. That 
is, the browser, not the sender, decides on the format. Clearly, one has to 
go lightly on the CSS in order for that to work, but it does work and it 
works pretty well. When that's done, the presentation changes to fit the 
browser's properties.

One could try to drop some of the data on very space limited devices, but 
that's usually the wrong way around: there ought to be a way to get more 
details on *all* devices. If you want an at-a-glance display, it can't be so 
small that I have to find reading glasses to see it (which means it has to 
be pretty large, even on my desktop).

Besides, just sending raw XML to a browser will get you very lame output. 
Something has to be presented to the browser in order make that presentation 
look better -- and that has to come from somewhere. And if not the car's 
server, where *is* it going to come from? From the "cloud", that master of 
all buzzwords, the home of instability, completely lose of privacy and 
freedom? Thanks, but no thanks. I don't want the user interface to my car to 
change every time I turn it on! Yet that's what happens in these idiot 
systems (my phone has done that several times in the time I've owned it) --  
I have better things to do than to relearn how to use my own car (or phone) 
every few weeks.

> Choosing XML addresses these issues, since the car's web server
> can be left alone when clients should change.

Again, how can the clients change? Where is that presentation coming from? I 
am not interested in putting my car on the public internet!

>> It might make
>> sense to use XML to send data to an app, but that's clearly the hard way 
>> to
>> do things.
>
> It seems the easiest, even in comparison to HTML, in that---for the
> service in question---everything needed to handle XML is in place,
> including transformation machinery.

If you're building an app, I agree that everything changes. But that's not 
the case I've been talking about, because it was not the case you set up --  
you specifically said *to show in a browser*.

                          Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Vasiliy Molostov" <molostoff@gmail.com> wrote in message 
news:op.wje1nc1hka8ora@aspire.local...
Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Wed, 22 Aug
2012 02:31:22 +0400:
>> Maybe, but it all sounds like a fantasy to me. (Much about XML sounds 
>> like pure fantasy to me.)
>
>Yep, like tasking in '80-90. It was a pure fantasy. But useful.

Surely it was a fantasy back then, but it was definitely not useful for 
anything beyond toy programs. Certainly not on PCs. It took until the 
Windows 95 era for CPUs to be powerful enough to justify the headaches that 
it introduced.

One the problems for Janus/Ada is that we designed our tasking system mainly 
so that we could pass validation. There was no attempt at efficiency or 
usability simply because it was a silly thing to use at the time (late 
1980s). So there were some design flaws that have made it hard to adapt to 
more modern systems where tasking actually has value.

>> Maintaining two ways to do the same thing is the ultimate in headaches --
>> you get to fix all bugs twice. For files not intended for use beyond the
>> compilation system, it doesn't make much sense to maintain more than one
>> version. (We don't attempt to keep any sort of compatibility on these 
>> files
>> now between different compiler versions.)
>
>No, as I see it that new thing can be on top of already existing one, and 
>this looks like an extension only, a king of.

Complicated sequential text files (which XML are) cannot be an extension of 
simple random-access binary files -- they're just too different. Besides, 
none of the data you are interested in is in the project file anyway; the 
declaration data is in the SYM files. We already have a simplified text 
version of the SYM files for the debugger (and for our debugging). One could 
imagine trying to make those into XML, but that would mean having to 
separate the debugging and debugger files (XML is not readable enough to use 
for debugging, especially as it is not uncommon for only part of the file to 
be written when there is a consistency problem that causes a crash in 
accessing the symbol table. That would prevent using an XML viewer to look 
at them).

>> One could imagine having tools to extract information from the project 
>> files
>> in some other format, but I doubt that we'd change the format a lot. (And
>> such tools would require customer demand, obviously.)
>
>This is one of the ways to attract more customers and minimize effort for 
>existing ones.
>A file can be just another one, does not matter.

Attempting to "attract customers" with off-the-wall ideas of unknown value 
is a good way to go out of business. (Let me tell you about RR's management 
in the late 1980s. Actually, better leave those stories left untold.) One 
needs existing and/or serious potential customers that need something to 
justify a lot of work. (That customer could be internal of course, which is 
where much of the HTML/HTTP support in Claw came from.)

                               Randy.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Randy Brukardt <randy@rrsoftware.com> писал(а) в своём письме Thu, 23 Aug  
2012 02:08:12 +0400:

> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message
> news:op.wje1nc1hka8ora@aspire.local...
> Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Wed, 22 Aug
> 2012 02:31:22 +0400:

> Attempting to "attract customers" with off-the-wall ideas of unknown  
> value
> is a good way to go out of business. (Let me tell you about RR's  
> management
> in the late 1980s. Actually, better leave those stories left untold.) One
> needs existing and/or serious potential customers that need something to
> justify a lot of work. (That customer could be internal of course, which  
> is
> where much of the HTML/HTTP support in Claw came from.)

These "off-the-wall" ideas are still the fact that any other (non-ada)  
developers use.
But yes, above make sense, I see, much of the effort is always a bussines,  
and then a programming.
And for bussines its very important to have an identity, but even a  
monopoly
(probably named as an unfair competitive advantage) in some utility field.

I can only jealously take a look at neighbour's dev-tools and go to fall  
in envy,
and this means that I feel my customer freedom is restricted in some  
general ways when I use Ada. :(
This tends to affect on design decisions and on customer's health in  
efforts he undertakes in a ways
that other non-ada developers already have left in their background  
advances.

So I suppose it is your identity and freedom you mean indeed. and I  
understand it.

Too late to think about monopoly, this looks more closely to isolation. :(  
Unfortunately.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Thu,  
23 Aug 2012 00:08:41 +0400:

> On Wed, 22 Aug 2012 21:59:36 +0200, Georg Bauhaus wrote:
>
>> On 22.08.12 19:44, Dmitry A. Kazakov wrote:
> Do you know a way to process PDF documents without parsing them? Then, do
> it!

Parsers are everywhere, even a printers capable to print native pdfs for  
now, even X11 has an postscript interpreter,
so there is no need to parse them in ada.

Even embedded devices use xml parsers to parse their flashed  
configuration. It is so basic as ini file parsers in '90,
and nobody complain on the planet about it, except yours, Dmitry.
You are already in the future, so adopt of this day as 'today' for  
yourself, please!

And these parsers want to have a common shared format to interchange data  
between each other, to bring ease into our life.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Shark8]

No

On Wednesday, August 22, 2012 12:14:17 AM UTC-6, Pascal Obry wrote:
> Le 22/08/2012 01:54, Shark8 a écrit :
> 
> > So? Why should everything be crammed into XML?
> 
> Can you quote where I did say everything?

No, I cannot. It was a poor choice-of-words/response on my part, reading into your post what was not said.

Re: Should Inline be private in the private part of a package spec?

[Niklas Holsti]

On 12-08-23 01:08 , Randy Brukardt wrote:
> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message 
> news:op.wje1nc1hka8ora@aspire.local...
> Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Wed, 22 Aug
> 2012 02:31:22 +0400:
>>> Maybe, but it all sounds like a fantasy to me. (Much about XML sounds 
>>> like pure fantasy to me.)
>>
>> Yep, like tasking in '80-90. It was a pure fantasy. But useful.
> 
> Surely it was a fantasy back then, but it was definitely not useful for 
> anything beyond toy programs.

I disagree. In that time interval I implemented useful real-time systems
using tasking with DEC Ada on MicroVAX/VMS. They were not large
programs, but they were production programs, not toys. Tasking worked
well for me in that environment.

> Certainly not on PCs. It took until the 
> Windows 95 era for CPUs to be powerful enough to justify the headaches that 
> it introduced.

The blame is probably due to the "toy" nature of early PCs and Windows.
"Real" computers were easily running multi-program, multi-threading
workloads at that time. Multi-threading real-time kernels for embedded
systems were well established, too.

> One the problems for Janus/Ada is that we designed our tasking system mainly 
> so that we could pass validation. There was no attempt at efficiency or 
> usability simply because it was a silly thing to use at the time (late 
> 1980s). So there were some design flaws that have made it hard to adapt to 
> more modern systems where tasking actually has value.

What kind of "value" are you thinking of? Increased performance through
parallel execution on multiple cores? Don't you agree that tasking also
is a valuable tool for the implementation of concurrent programs on
single cores? For the programs that I mentioned at the top of this post,
the users saw significant real-time performance improvements through
concurrent operation of peripherals and the ability to continue
application functions (especially data acquisition functions) without
breaks.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
      .      @       .

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On 22 Aug 2012 20:29:13 GMT, Georg Bauhaus wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>> On Wed, 22 Aug 2012 21:59:36 +0200, Georg Bauhaus wrote:
>> 
>>> On 22.08.12 19:44, Dmitry A. Kazakov wrote:
>>>>> I need to write many parsers if I can't use XML. I use data not
>>>>>> generated by our programs.
>>>> In that case this is irrelevant to the issue. Other programs use formats
>>>> they do. If that requires parsing that is their problem.
>>> 
>>> Next time I download a PDF from A Big Bank or from a corporation,
>>> destined to be a PDF document, I'll tell them that it is their
>>> problem if I need to parse it.
>> 
>> Do you know a way to process PDF documents without parsing them? Then, do
>> it!
> 
> How is my parsing their problem?

Who cares?

You said that XML is necessary because PDF requires parsing as well as XML
does. By this logic pigs can fly.

> If they did use XML then my life would be easier.

If they didn't it would be much easier.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Wed, 22 Aug 2012 23:18:16 +0200, Georg Bauhaus wrote:

> On 22.08.12 19:44, Dmitry A. Kazakov wrote:
>> On Wed, 22 Aug 2012 18:48:03 +0200, Georg Bauhaus wrote:
>>
>>> On 22.08.12 16:30, Dmitry A. Kazakov wrote:
>>>
>>>>> As always, the question is inefficient for what and for whom.
>>>>
>>>> For the network and the peers. The measures for both can be easily
>>>> provided.
>>>
>>> Well, that would depend on the specifics of "network" and its mode
>>> of use, wouldn't it?
>>
>> There exist pretty general measures, e.g. number of bits, FLOPs, QoS and so
>> on.
> 
> In the set called "and so on", information retrieval programs will
> be efficient at all once they can interpret a data item to be an object
> for which FLOPs make any sense.

and XML stands in their way.

> That's easier to see when there is
> markup than when the program needs to guess if some four octets
> could be a float.

Wasting time and memory. It is also fundamentally inconsistent, but that is
beside the point.

>>>>>> 2. fails to capture the structure (e.g. recursive, interlinked structures)
>>>>>
>>>>> ?
>>>>
>>>> Take Containers.Doubly_Linked_Lists as an example. The closure object of a
>>>> list is the structure in question.
>>>
>>> "closure object" = ?
>>
>> Linked list is not an object. An object could be a closure of the list upon
>> the relation predecessor-successor, e.g. a set of linked nodes.
> 
> So the closure could be mapped to ... what if not an object?

Object where? Everything can be an object somewhere. It is meaningless
until you specify where.

> XML will not require complex, resource consuming, vulnerable parsers
> once applications need not input non-XML data, such as Excel files
> or HTML pages.

So it is the Excel's fault that XML requires parsing? (Can't wait your
mobile phone camera's would send each pixel in XML. The brave new world.)

>> Ada is not proposed for exchanging structured data
>> between computers.
> 
> It is, however, required to say how to exchange structured program
> source text between compilers.

No
 
>> Ada is a programming language. XML in this context plays
>> the role of a protocol to exchange above mentioned data.
> 
> No. It is a markup language for tagging data in text documents.
> We have been here before.

That is it! XML is not for exchange of structured data.

q.e.d.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 22.08.12 23:55, Randy Brukardt wrote:

>> Zeroth, a setup that sends plain HTML does not meet the usual
>> requirements for presenting information to end users (excluding
>> engineers who would be happy just seeing some text).
>
> Baloney.

Measured by the amount of money flowing into design of ever new
packaging for the umpteenth time, not baloney. As I said, engineers
might have some exclusive views...


>> First, HTML is inflexible in that you cannot choose a natural
>> vocabulary for car information.
>
> Who gives a f*** about a "vocabulary"?

Ada software engineers are asked to use a domain specific vocabulary
in their program (which here is about car status). The status web
server engineers can be asked the same when producing tagged text
they then delegate to the web guys who write the XSLT to be run in
the browser. I think Vasiliy already indicated how. And yes, it has
to come from somewhere.

Defining the vocabulary and defining the grammar is another opportunity
for engineers to make their education bear fruit. Can't do this using HTML.

Granted, I said browser, not app, although today many customers do not
distinguish them. But even then, HTML may be produced from the domain
specific XML document by referring to an XSLT in an XML processing
instruction. (And the transformation program may be cached in the
device, unlike the car's status). One consequence is separation of
concerns, since status engineers will not have to change output
procedures if rendering is to be changed. Additionally, the CSS may
well be delivered by the company web servers, not the car's. Yes,
there are limits to what a browser can do, largely because our
software industry has invented the fully qualified host name as the
principal item of security.

The point why I am saying all this in an Ada context is that I can't
help but think that many Ada programmers are stopping to think the Ada way
(should that exist) once the subject matter changes just a little,
for example, to XML syntax. (General purpose language, large systems,
subsystems, packages, decoupling, name equivalence of types ...)

> Apparently, you have completely forgotten the original purpose of HTML. That
> is, the browser, not the sender, decides on the format.

I always agreed with the original intent of HTML. The market has not
agreed. Not at all. Sometimes even within reason: What kind of web pages
need to have section headings? So still, HTML does not allow for the
separation of content and format as well as XML. Not surprisingly
at that, since HTML was not meant to be as general purpose as SGML.

So I'll happily embrace the idea that the product should be an app
if this helps clears the path for better software engineering.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 09:06, Dmitry A. Kazakov wrote:
> On 22 Aug 2012 20:29:13 GMT, Georg Bauhaus wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>> On Wed, 22 Aug 2012 21:59:36 +0200, Georg Bauhaus wrote:
>>>
>>>> On 22.08.12 19:44, Dmitry A. Kazakov wrote:
>>>>>> I need to write many parsers if I can't use XML. I use data not
>>>>>>> generated by our programs.
>>>>> In that case this is irrelevant to the issue. Other programs use formats
>>>>> they do. If that requires parsing that is their problem.
>>>>
>>>> Next time I download a PDF from A Big Bank or from a corporation,
>>>> destined to be a PDF document, I'll tell them that it is their
>>>> problem if I need to parse it.
>>>
>>> Do you know a way to process PDF documents without parsing them? Then, do
>>> it!
>>
>> How is my parsing their problem?
>
> Who cares?
>
> You said that XML is necessary because PDF requires parsing as well as XML
> does. By this logic pigs can fly.

I said that since there are multiple different source (Excel, PDF, ...)
I need *more* parsing. If all sources use XML, the variety of parsers is
reduced. (For more, see the next sentence.)

>> If they did use XML then my life would be easier.
>
> If they didn't it would be much easier.

No, as Pascal Obry has expounded two days ago, in the real, non-standard
world that some of us live in, we would not even enjoy the luxury of a
known file format such as Excel or PDF.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Thu, 23 Aug 2012 10:08:25 +0200, Georg Bauhaus wrote:

> On 23.08.12 09:06, Dmitry A. Kazakov wrote:
>> On 22 Aug 2012 20:29:13 GMT, Georg Bauhaus wrote:
>>
>>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:
>>>> On Wed, 22 Aug 2012 21:59:36 +0200, Georg Bauhaus wrote:
>>>>
>>>>> On 22.08.12 19:44, Dmitry A. Kazakov wrote:
>>>>>>> I need to write many parsers if I can't use XML. I use data not
>>>>>>>> generated by our programs.
>>>>>> In that case this is irrelevant to the issue. Other programs use formats
>>>>>> they do. If that requires parsing that is their problem.
>>>>>
>>>>> Next time I download a PDF from A Big Bank or from a corporation,
>>>>> destined to be a PDF document, I'll tell them that it is their
>>>>> problem if I need to parse it.
>>>>
>>>> Do you know a way to process PDF documents without parsing them? Then, do
>>>> it!
>>>
>>> How is my parsing their problem?
>>
>> Who cares?
>>
>> You said that XML is necessary because PDF requires parsing as well as XML
>> does. By this logic pigs can fly.
> 
> I said that since there are multiple different source (Excel, PDF, ...)
> I need *more* parsing.

Wrong. That depends on what parsing the involved sources require. You imply
that:

   n1 * P1 + n2 * P2 > (n1 + n2) * P1

for any P1 and P2. This is plain wrong.

> If all sources use XML, the variety of parsers is reduced.

I don't need parsers to exchange data: P1 = 0.

>>> If they did use XML then my life would be easier.
>>
>> If they didn't it would be much easier.
> 
> No, as Pascal Obry has expounded two days ago,

He proposed XML for exchanging structured data. You already agreed in this
thread that XML would be a poor performer there.

> in the real, non-standard
> world that some of us live in, we would not even enjoy the luxury of a
> known file format such as Excel or PDF.

In the real non-standard world there are requirements imposed on the
application and there are solutions and decisions you are free to make.

The point is straight and simple: when you are free to choose never ever
use XML. There is no technical reason to choose XML.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 09:23, Dmitry A. Kazakov wrote:

> and XML stands in their way.

If XML stands in your way, OK. This seems to be about your nicely
integrated car networks where every party knows what to expect
and what to produce, and how to agree.
If you want to keep XML out of these internal, documented networks,
I totally agree with this.
But this is very specific to a situation that funds definitions
and agreements.

>> That's easier to see when there is
>> markup than when the program needs to guess

> Wasting time and memory.

So laborious guessing, looking for clues, is cheaper than just looking
at a tag that clearly identifies the intent of the tagged item?

Remember: in my networks I work more like an archaeologist trying
to understand the shards. That's easier when there are additional
hints like: found next to this one; has half a word printed on it.

> So it is the Excel's fault that XML requires parsing?

It feels too stupid to answer that again, sorry.
Roughly, N parsers > 1 parsers if N > 1. Roughly.

>>> Ada is not proposed for exchanging structured data
>>> between computers.
>>
>> It is, however, required to say how to exchange structured program
>> source text between compilers.
>
> No

Yes, it is. Character set support, documentation requirements, ...

Without what has become Ada, consider some 400 compilers and assemblers
translate programs written in some 400 different languages.
In order to transform them from some language to some target
language Ada, you need some 400 parsers. Or maybe, all would essentially
need to be compiled in the first place

Obviously, we need at least 1 parser even if only 1 programming
language remains.

Similarly, XML, or any agreed-upon way of exchanging data,
can remove some of the mess in data exchange, but will need
some kind of parsing. In any non-internal network.

>>> Ada is a programming language. XML in this context plays
>>> the role of a protocol to exchange above mentioned data.
>>
>> No. It is a markup language for tagging data in text documents.
>> We have been here before.
>
> That is it! XML is not for exchange of structured data.

No, XML is not a protocol for whatsoever.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 09:56, Georg Bauhaus wrote:
> So still, HTML does not allow for the
> separation of content and format as well as XML.
                                              insert: does. sorry.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 10:38, Dmitry A. Kazakov wrote:

>> I said that since there are multiple different source (Excel, PDF, ...)
>> I need *more* parsing.
>
> Wrong. That depends on what parsing the involved sources require.

Here is the effort, per document:

  XML1 * Parsing_Effort (XML1)
   + XML2 * Parsing_Effort (XML2)
   + XML3 * Parsing_Effort (XML3)

vs

  Excel * Parsing_Effort (Excel)
   + PDF * Parsing_Effort (PDF)
   + ... * Parsing_Effort (...)

If you have had the pleasure of parsing a man made Excel or PDF file,
you know the result of the comparison. One could of course
throw a couple of monthly salaries at MS and Adobe and buy all necessary
versions of Excel and Acrobat and all necessary development tools
(if available at all) just to get at those cells of the data sheets,
hoping that results will be produced in time.

>> If all sources use XML, the variety of parsers is reduced.
>
> I don't need parsers to exchange data: P1 = 0.

Fine. Most people will need some parsing in their networks.


> He proposed XML for exchanging structured data. You already agreed in this
> thread that XML would be a poor performer there.

If XML means sending less information per second, then still understanding
the information in XML documents can be *much* faster and require *less*
development time.
These timings matter much more in a market for software that does
not take years to design and does not run for decades.


>> in the real, non-standard
>> world that some of us live in, we would not even enjoy the luxury of a
>> known file format such as Excel or PDF.
>
> In the real non-standard world there are requirements imposed on the
> application and there are solutions and decisions you are free to make.

Requirement: find the information before it becomes obsolete.
Choice: write a parser, or parse manually, whichever is quicker.
Imposed conditions: documents exist, as-is, in the network.

> The point is straight and simple: when you are free to choose never ever
> use XML. There is no technical reason to choose XML.

For weeks now I have been trying to explain that in my networks,
there is no plural "you". There are multiple "we"s. They do *not*
agree. Everyone sends what they think is the right choice. Period.
In *this* kind of network, XML is a relief.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Thu, 23 Aug 2012 10:56:57 +0200, Georg Bauhaus wrote:

> On 23.08.12 09:23, Dmitry A. Kazakov wrote:
> 
>> and XML stands in their way.
> 
> If XML stands in your way, OK.

Here is the exchange you cut:

> On Wed, 22 Aug 2012 23:18:16 +0200, Georg Bauhaus wrote:
>> On 22.08.12 19:44, Dmitry A. Kazakov wrote:
>>> On Wed, 22 Aug 2012 18:48:03 +0200, Georg Bauhaus wrote:
>>>> On 22.08.12 16:30, Dmitry A. Kazakov wrote:
>>>>>> As always, the question is inefficient for what and for whom.
>>>>> For the network and the peers. The measures for both can be easily
>>>>> provided.
>>>> Well, that would depend on the specifics of "network" and its mode
>>>> of use, wouldn't it?
>>> There exist pretty general measures, e.g. number of bits, FLOPs, QoS and so
>>> on.
>> In the set called "and so on", information retrieval programs will
>> be efficient at all once they can interpret a data item to be an object
>> for which FLOPs make any sense.
> and XML stands in their way.

>>> That's easier to see when there is
>>> markup than when the program needs to guess
> 
>> Wasting time and memory.
> 
> So laborious guessing, looking for clues, is cheaper than just looking
> at a tag that clearly identifies the intent of the tagged item?

Nobody needs either parsing or guessing in order to exchange structured
data. Things you describe maybe are consequences of deployment of XML, but
they are in no way the premises.

> Remember: in my networks I work more like an archaeologist trying
> to understand the shards.

There are many thing one could do wrong. Using XML was seemingly not the
only one. If you and others would not deploy XML in your networks, the
"ceramic" would have been intact.

>>>> Ada is not proposed for exchanging structured data
>>>> between computers.
>>>
>>> It is, however, required to say how to exchange structured program
>>> source text between compilers.
>>
>> No
> 
> Yes, it is. Character set support, documentation requirements, ...

see RM 2.1 regarding Ada character set and for the rest. The purpose of the
language is described in RM 1.

Otherwise, I repeat: Ada is not proposed for exchanging structured data.
Thus any references to Ada are irrelevant.

>>>> between computers.

>>>> Ada is a programming language. XML in this context plays
>>>> the role of a protocol to exchange above mentioned data.
>>>
>>> No. It is a markup language for tagging data in text documents.
>>> We have been here before.
>>
>> That is it! XML is not for exchange of structured data.
> 
> No, XML is not a protocol for whatsoever.

Either

   "Yes, XML is not a protocol for whatsoever."

or

   "No, XML is a protocol for exchange of structured data."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Thu, 23 Aug 2012 11:58:24 +0200, Georg Bauhaus wrote:

> On 23.08.12 10:38, Dmitry A. Kazakov wrote:
> 
>> The point is straight and simple: when you are free to choose never ever
>> use XML. There is no technical reason to choose XML.
> 
> For weeks now I have been trying to explain that in my networks,

For weeks your are trying to explain how wrong decisions led or might lead
to XML. I don't argue with that. I merely state that neither of these
decisions could be necessary due to technical reasons.

Human error /= technical reason

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 12:27, Dmitry A. Kazakov wrote:
> On Thu, 23 Aug 2012 11:58:24 +0200, Georg Bauhaus wrote:
> 
>> On 23.08.12 10:38, Dmitry A. Kazakov wrote:
>>
>>> The point is straight and simple: when you are free to choose never ever
>>> use XML. There is no technical reason to choose XML.
>>
>> For weeks now I have been trying to explain that in my networks,
> 
> For weeks your are trying to explain how wrong decisions led or might lead
> to XML. I don't argue with that. I merely state that neither of these
> decisions could be necessary due to technical reasons.
> 
> Human error /= technical reason

To err is human. To fail is technical.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 12:13, Dmitry A. Kazakov wrote:
> Nobody needs either parsing or guessing in order to exchange structured
> data.

Nobody needs either parsing or guessing in order to understand data
of *known* structure. Which is the point. When endpoints lack this
knowledge and there exists no way of obtaining the knowledge from
elsewhere, then hints in the data will help.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 12:13, Dmitry A. Kazakov wrote:
>>>>> Ada is a programming language. XML in this context plays
>>>>> >>>> the role of a protocol to exchange above mentioned data.
>>>> >>>
>>>> >>> No. It is a markup language for tagging data in text documents.
>>>> >>> We have been here before.
>>> >>
>>> >> That is it! XML is not for exchange of structured data.
>> > 
>> > No, XML is not a protocol for whatsoever.
> Either
> 
>    "Yes, XML is not a protocol for whatsoever."
> 
> or
> 
>    "No, XML is a protocol for exchange of structured data."

or

"No, XML does not play the role of a protocol."

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 12:13, Dmitry A. Kazakov wrote:
> Ada is not proposed for exchanging structured data.

XML is proposed for exchanging data between unknown endpoints,
for reasons similar to those that have produced Ada and its syntax.

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Thu, 23 Aug 2012 13:30:17 +0200, Georg Bauhaus wrote:

> On 23.08.12 12:27, Dmitry A. Kazakov wrote:
>> On Thu, 23 Aug 2012 11:58:24 +0200, Georg Bauhaus wrote:
>> 
>>> On 23.08.12 10:38, Dmitry A. Kazakov wrote:
>>>
>>>> The point is straight and simple: when you are free to choose never ever
>>>> use XML. There is no technical reason to choose XML.
>>>
>>> For weeks now I have been trying to explain that in my networks,
>> 
>> For weeks your are trying to explain how wrong decisions led or might lead
>> to XML. I don't argue with that. I merely state that neither of these
>> decisions could be necessary due to technical reasons.
>> 
>> Human error /= technical reason
> 
> To err is human. To fail is technical.

Sort of. However failure is only our interpretation. Physical systems
always behave as they must according to the laws of nature. If we do not
like it, we have to change the corresponding system.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Thu, 23 Aug 2012 13:39:32 +0200, Georg Bauhaus wrote:

> On 23.08.12 12:13, Dmitry A. Kazakov wrote:
>> Ada is not proposed for exchanging structured data.
> 
> XML is proposed for exchanging data between unknown endpoints,

not (X in A) |=
not (X in (A and B))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Dmitry A. Kazakov]

On Thu, 23 Aug 2012 13:33:57 +0200, Georg Bauhaus wrote:

> On 23.08.12 12:13, Dmitry A. Kazakov wrote:
>> Nobody needs either parsing or guessing in order to exchange structured
>> data.
> 
> Nobody needs either parsing or guessing in order to understand data
> of *known* structure. Which is the point.

Structured data cannot have unknown structure. Furthermore, you already
tried to praise XML for being able to define a structure. Now if the
structure is unknown, then the structure the XML description promotes maps
to what? It is even worse than to inadequately describe something existent.
What XML would do in this case would be outright lie.

But of course, you didn't meant that. You meant a tautology: a description
of an object describes the object (and its structure as well).

> When endpoints lack this
> knowledge and there exists no way of obtaining the knowledge from
> elsewhere, then hints in the data will help.

Nonsense. When an object is transmitted so goes its structure whatever it
be. As such it cannot be unknown to the peer which reconstructs the object
by deserializing it. If the structure were unknown but necessary, the
object could not be deserialized.

But we are running in circles. The capacities of XML for describing
structures of complex objects was already discussed. See
Ada.Containers.Doubly_Linked_Lists.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Thu,  
23 Aug 2012 16:45:58 +0400:

> On Thu, 23 Aug 2012 13:33:57 +0200, Georg Bauhaus wrote:
> Structured data cannot have unknown structure.

Wrong. Known it is or not known, it is not a property of structure itself,  
but a property of an observer's view (ada introduced 'views' btw in RM).  
If some observer can not see the structure through his obscure view this  
does not mean that there is no structure at all.

As for Ada - record types are structured data, well transformed into xml,  
keeping not only type name and its constraints but also a name of record  
member, even a package name where it is defined.

Fundamentally, all the language you mention (Ada) is build on top of the  
idea exchanging there records between
subprograms and file (or stream) objects.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 14:33, Dmitry A. Kazakov wrote:
> On Thu, 23 Aug 2012 13:39:32 +0200, Georg Bauhaus wrote:
> 
>> On 23.08.12 12:13, Dmitry A. Kazakov wrote:
>>> Ada is not proposed for exchanging structured data.
>>
>> XML is proposed for exchanging data between unknown endpoints,
> 
> not (X in A) |=
> not (X in (A and B))

I think you are missing the motive part of the argument
and its restriction to syntax.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 14:45, Dmitry A. Kazakov wrote:
> you already
> tried to praise XML for being able to define a structure. Now if the
> structure is unknown, then the structure the XML description promotes maps
> to what?

DC. I have the freedom of choice: I only need bits of information,
since I am *not* deserializing someone else's supposedly serialized
object.
I write constructors, or initializers, that use information dug
up from external sources without referring to their origin in any
way, without requiring complete structures or anything: there
are pieces of text that let me write a program that makes the
interesting information available.
I am interested in signals in the noise.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 23.08.12 15:31, Vasiliy Molostov wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> писал(а) в своём письме Thu, 23
> Aug 2012 16:45:58 +0400:
> 
>> On Thu, 23 Aug 2012 13:33:57 +0200, Georg Bauhaus wrote:
>> Structured data cannot have unknown structure.
> 
> Wrong. Known it is or not known, it is not a property of structure itself, but
> a property of an observer's view (ada introduced 'views' btw in RM). If some
> observer can not see the structure through his obscure view this does not mean
> that there is no structure at all.

Exactly.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:5035e241$0$6584$9b4e6d93@newsspool3.arcor-online.net...
> On 22.08.12 23:55, Randy Brukardt wrote:
...
>>> First, HTML is inflexible in that you cannot choose a natural
>>> vocabulary for car information.
>>
>> Who gives a f*** about a "vocabulary"?
>
> Ada software engineers are asked to use a domain specific vocabulary
> in their program (which here is about car status). The status web
> server engineers can be asked the same when producing tagged text
> they then delegate to the web guys who write the XSLT to be run in
> the browser. I think Vasiliy already indicated how. And yes, it has
> to come from somewhere.

You need to go to "Overengineering Anonymous". The original problem 
statement was "send to a browser", which means HTML has to be present 
somewhere. All the rest of this is huge amounts of overkill.

                       Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a9m2seF5clU1@mid.individual.net...
> On 12-08-23 01:08 , Randy Brukardt wrote:
>> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message
>> news:op.wje1nc1hka8ora@aspire.local...
>> Randy Brukardt <randy@rrsoftware.com> ?????(?) ? ????? ?????? Wed, 22 Aug
>> 2012 02:31:22 +0400:
>>>> Maybe, but it all sounds like a fantasy to me. (Much about XML sounds
>>>> like pure fantasy to me.)
>>>
>>> Yep, like tasking in '80-90. It was a pure fantasy. But useful.
>>
>> Surely it was a fantasy back then, but it was definitely not useful for
>> anything beyond toy programs.
>
> I disagree. In that time interval I implemented useful real-time systems
> using tasking with DEC Ada on MicroVAX/VMS. They were not large
> programs, but they were production programs, not toys. Tasking worked
> well for me in that environment.
>
>> Certainly not on PCs. It took until the
>> Windows 95 era for CPUs to be powerful enough to justify the headaches 
>> that
>> it introduced.
>
> The blame is probably due to the "toy" nature of early PCs and Windows.
> "Real" computers were easily running multi-program, multi-threading
> workloads at that time. Multi-threading real-time kernels for embedded
> systems were well established, too.

True, there were multitasking machines at the time. But most Ada compilers 
mapped into a single process (the idea of "thread" not having been added to 
most OSes at that time), so you didn't get any of the advantages of that.

>> One the problems for Janus/Ada is that we designed our tasking system 
>> mainly
>> so that we could pass validation. There was no attempt at efficiency or
>> usability simply because it was a silly thing to use at the time (late
>> 1980s). So there were some design flaws that have made it hard to adapt 
>> to
>> more modern systems where tasking actually has value.
>
> What kind of "value" are you thinking of? Increased performance through
> parallel execution on multiple cores? Don't you agree that tasking also
> is a valuable tool for the implementation of concurrent programs on
> single cores? For the programs that I mentioned at the top of this post,
> the users saw significant real-time performance improvements through
> concurrent operation of peripherals and the ability to continue
> application functions (especially data acquisition functions) without
> breaks.

Multicore execution, primarily. I do agree that there is value to using 
tasks as a structuring element (they're used extensively in my spam filter 
and web server, for obvious reasons). But back in the 1990s, we had to 
operate much closer to the metal, and the high overhead of tasking 
(especially within a single process tasking) could only be justified in 
programs with quite lax service requirements.

To take an example, the server that runs the web server is an ancient single 
core machine (900MHZ, I think). But it still is 110 times faster than the 
8086 that I was using in the early days of Janus/Ada. (And the difference 
was probably greater than that, as that was a high-powered 16-bit machine 
[for the time, of course]; the server is 32-bit, of course). The tasking 
overhead is much less of a problem on such a machine (context switch times 
are a few microseconds rather than a few milliseconds), so one can use 
tasking productively. (And of course, our IBM PC/XT was about 3 times slower 
than the 8086 machine, which is what most people had.)

I had used bigger iron at the University of Wisconsin, (VAX 780s, for 
instance), but those had slowed to a crawl toward the end of semesters when 
everyone's projects were coming due. I doubt that they would have been happy 
doubling the overhead of running a program for the "benefit" of 
multitasking.

Surely tasking is useful *now*, and that's all that really matters. Ada was 
just a couple of decades ahead of its time.

                           Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Vasiliy Molostov" <molostoff@gmail.com> wrote in message 
news:op.wjgv6v1fka8ora@aspire.local...
...
>And these parsers want to have a common shared format to interchange data 
>between each other, to bring ease into our life.

And criminals. And marketers, and government snoops. And they'll get a *lot* 
more benefit from this than you ever will.

Thanks, but no tanks. I prefer to limit sharing as much as possible.

              Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:50361675$0$6582$9b4e6d93@newsspool3.arcor-online.net...
> On 23.08.12 12:13, Dmitry A. Kazakov wrote:
>> Ada is not proposed for exchanging structured data.
>
> XML is proposed for exchanging data between unknown endpoints,
> for reasons similar to those that have produced Ada and its syntax.

Data should never be exchanged with "unknown endpoints", because there is 
then no way to judge the reliability of the data. (And there are lots of 
people who would like to corrupt it.)

Ergo, XML is proposed to solve a problem which simply should never arise.

                              Randy.

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Randy Brukardt <randy@rrsoftware.com> писал(а) в своём письме Fri, 24 Aug  
2012 08:40:09 +0400:

> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message
> news:op.wjgv6v1fka8ora@aspire.local...
> ...
>> And these parsers want to have a common shared format to interchange  
>> data
>> between each other, to bring ease into our life.
>
> And criminals. And marketers, and government snoops. And they'll get a  
> *lot*
> more benefit from this than you ever will.
>
> Thanks, but no tanks. I prefer to limit sharing as much as possible.

And a Big Taiwan-konaut, just from a great wall space satellite.

You still can zip/encrypt your xml data in this case. But for selected  
reader it is much better to decrypt/read and process
data when it is unified in some neutral way, and xml is just a form of.

You still can complain about anonymouses and viruses inside these dark xml  
related matters,
but the way people go - structured text, you can not change it.

YOur preference to limit is an issue of your customer adopting such limit  
in his development workflow.

>
>               Randy.
>
>
>
>


-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 24.08.12 06:48, Randy Brukardt wrote:
> "Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
> news:50361675$0$6582$9b4e6d93@newsspool3.arcor-online.net...
>> On 23.08.12 12:13, Dmitry A. Kazakov wrote:
>>> Ada is not proposed for exchanging structured data.
>>
>> XML is proposed for exchanging data between unknown endpoints,
>> for reasons similar to those that have produced Ada and its syntax.
> 
> Data should never be exchanged with "unknown endpoints", because there is 
> then no way to judge the reliability of the data. (And there are lots of 
> people who would like to corrupt it.)

The argument is bogus, because it assumes "known endpoints" send more
reliable data just because they are known. If you know the origin,
you still do not know what will be input.
If you assume criminals, than knowledge of criminal techniques
forces all I/O to be written assuming counterfeit.
Examples of failing security setups are readily available.
This has little to do with deciphering Ada.Streams or deciphering
XML documents.

The argument is also bogus if it implies that programs should
never read any input unless they know with certainty what will
be input. This excludes research programs that must try find
signals in noise, search patterns in the chaos, or look for
needles in the hay stack.


> Ergo, XML is proposed to solve a problem which simply should never arise.

More like a generalization of a very special case...

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 24.08.12 06:40, Randy Brukardt wrote:
> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message 
> news:op.wjgv6v1fka8ora@aspire.local...
> ...
>> And these parsers want to have a common shared format to interchange data 
>> between each other, to bring ease into our life.
> 
> And criminals. And marketers, and government snoops. And they'll get a *lot* 
> more benefit from this than you ever will.
> 
> Thanks, but no tanks. I prefer to limit sharing as much as possible.

That's fine, but surely you don't want an ad of an Ada compiler
to fail because the other end is not prepared to fully input your
binary description? The number of WordPerfect documents advertising
products has diminished, I should think. Presenting the same material
in XHTML works better, even when some readers have interest only
in specific parts they can identify.

Re: Should Inline be private in the private part of a package spec?

[Georg Bauhaus]

On 24.08.12 06:22, Randy Brukardt wrote:

>> Ada software engineers are asked to use a domain specific vocabulary
>> in their program (which here is about car status). The status web
>> server engineers can be asked the same when producing tagged text
>> they then delegate to the web guys who write the XSLT to be run in
>> the browser. I think Vasiliy already indicated how. And yes, it has
>> to come from somewhere.
> 
> You need to go to "Overengineering Anonymous". The original problem 
> statement was "send to a browser", which means HTML has to be present 
> somewhere. All the rest of this is huge amounts of overkill.

This is the way larger customers produce software based systems.
The procedures are such that several teams work at their own pace.
Changes need to be made to modules of the system, if possible.
It is not the kind of system where you have a single server
maintained by a single team. The HTML+CSS+... needs to be the
result of they system's modules working.

You can't have all customers of ${car maker} drive their cars
to the next shop to have staff install an updated part of
a web page, can you?

Re: Should Inline be private in the private part of a package spec?

[Vasiliy Molostov]

Georg Bauhaus <rm.dash-bauhaus@futureapps.de> писал(а) в своём письме Fri,  
24 Aug 2012 14:17:20 +0400:

> You can't have all customers of ${car maker} drive their cars
> to the next shop to have staff install an updated part of
> a web page, can you?

It is probably might be a horrible situation, but some business people  
find it as a good way to provide some utility "customer care" services,  
for some revenue. A dark side...

It makes no sense to criticize their business, but we always have the  
opportunity to get the desired result without such service, unless the  
capability is not taken away forcibly and deliberately. In this way all  
things and points become clear - customer should always pay for his own  
inconvenience.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:50375153$0$6573$9b4e6d93@newsspool3.arcor-online.net...
> On 24.08.12 06:40, Randy Brukardt wrote:
>> "Vasiliy Molostov" <molostoff@gmail.com> wrote in message
>> news:op.wjgv6v1fka8ora@aspire.local...
>> ...
>>> And these parsers want to have a common shared format to interchange 
>>> data
>>> between each other, to bring ease into our life.
>>
>> And criminals. And marketers, and government snoops. And they'll get a 
>> *lot*
>> more benefit from this than you ever will.
>>
>> Thanks, but no tanks. I prefer to limit sharing as much as possible.
>
> That's fine, but surely you don't want an ad of an Ada compiler
> to fail because the other end is not prepared to fully input your
> binary description? The number of WordPerfect documents advertising
> products has diminished, I should think. Presenting the same material
> in XHTML works better, even when some readers have interest only
> in specific parts they can identify.

Funny, I've been suggesting using HTML since the beginning. And obviously, 
you don't need to limit true broadcast information (information that you 
want everyone to have). But that's a small percentage of all information.

Anyway, you guys (and most of the world) are on the road to hell. [Aside: 
not intended to be a religious comment.] I'd rather not take that particular 
journey.

                    Randy.

Re: Should Inline be private in the private part of a package spec?

[Randy Brukardt]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:503754ae$0$6582$9b4e6d93@newsspool3.arcor-online.net...
> On 24.08.12 06:22, Randy Brukardt wrote:
>
>>> Ada software engineers are asked to use a domain specific vocabulary
>>> in their program (which here is about car status). The status web
>>> server engineers can be asked the same when producing tagged text
>>> they then delegate to the web guys who write the XSLT to be run in
>>> the browser. I think Vasiliy already indicated how. And yes, it has
>>> to come from somewhere.
>>
>> You need to go to "Overengineering Anonymous". The original problem
>> statement was "send to a browser", which means HTML has to be present
>> somewhere. All the rest of this is huge amounts of overkill.
>
> This is the way larger customers produce software based systems.
> The procedures are such that several teams work at their own pace.
> Changes need to be made to modules of the system, if possible.

Sure, you need good interfaces. XML does nothing to help there (as Dmitry 
has pointed out continually, and you pointed out yourself by babbling about 
"vocabulary").

> It is not the kind of system where you have a single server
> maintained by a single team. The HTML+CSS+... needs to be the
> result of they system's modules working.
>
> You can't have all customers of ${car maker} drive their cars
> to the next shop to have staff install an updated part of
> a web page, can you?

If you need to update a web page, your processes have already failed. No one 
needs (nor should want) to change the presentation of data every few weeks; 
so long as the data is presented accurately (which is the point of testing 
and verification), nothing ever needs to change.

                  Randy.