Re: discriminant questions

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 27 Sep 2011 20:06:35 +0200, Georg Bauhaus wrote:

> On 27.09.11 17:38, Dmitry A. Kazakov wrote:
>> On Tue, 27 Sep 2011 17:11:03 +0200, Georg Bauhaus wrote:
>> 
>>> On 27.09.11 14:14, Dmitry A. Kazakov wrote:
>>>> On Tue, 27 Sep 2011 12:18:28 +0200, Georg Bauhaus wrote:
>>>>
>> [...]
>>>  So you end up explaining tasks
>>> and protected objects anyway.  And you might be able to explain
>>> why seemingly advantageous "primitives" like "concurrent" and
>>> "lock" had been preferred to a library based approach.
>> 
>> As another example take elliptic integral of the first kind: F(x,k).
> 
> I had been talking about programming constructs, not specialized
> mathematical functions that may or may not be expressed in terms
> of more primitive mathematical functions.

A difference?

> That is, I'm assuming that programmers want a loop construct
> in Ada, not just goto.

Or recursion, or callbacks from some hidden iteration loop?

> I'm assuming that they don't want to have to define loop in
> terms of goto, even when this has certain advantages.

Do you think that they want to iterate containers using iterators?

My point is that loop as primitive should apply to user-defined stuff, like
containers. That means that the language should allow to "override" not
only the loop's body, but also its continue-or-exit part.

> I'm assuming that if programmers always had to build
> (or have someone do it for them) specific concurrency constructs
> out of concurrency primitives, than this is too time consuming.

Sorry, but this is what parallel programming is about.

> The of mine, quoted above, came out wrong: it should say that
> "task" and "protected object" were chosen, not CAS or some such,
> with libraries around it.

Tasks are not equivalent to CAS, you cannot create a task using CAS. You
need tasks independently on presence of CAS.

> There is a staircase, so to speak, from very primitive features
> up to more "heavy" features.

No. There is a huge difference between what is "heavy" 1) for machine, 2)
for programmer, 3) for customer. As an example take square root. Is it
"primitive"?

> Yes, in Ada 2012 we may reinvent basics in terms of more primitive
> language features such as conditional goto, 'Succ/'Pred, and
> and increment and decrement operations:
[...]

Don't confuse language construction with the Hilbert's program!

>> Why
>> bother to with subprograms, accuracy of real types, real types themselves,
>> approximation techniques for such a simple thing?
> 
> Ada's way of specifying fundamental types refers to concepts
> relatively far away from hardware, IMO.

While the field "pattern" is "double", it this what are you saying? Ada has
a more general concept, which is not heavier than "double", neither for the
hardware, nor for the programmer, nor for the customers. This is the right
way to design a good language.

>> The answer to your question was given by Occam 700 years ago.
> 
> How much hair would the rasor have cut from Ada's definition
> of its heavy concurrency primitives?

Heavy? Do you think that messages, channels, mutexes, events would be
lighter?

Anyway, the performance burden is not directly bound to being fundamental.
E.g. static types as a generalization of data value are for free.
 
> A question related to the "reach" of features: Are there patterns
> of programming embedded control software that could very well
> be reflected in language features?  I think they are, but not
> in Ada, which is too primitive here.

Nope, the patterns used in embedded control systems I am dealing with are
so rustic, that they better fit to an assembler or C. Ada is rocket science
compared to them.

>>> At Ada-auth, they usually say something about customer response to
>>> implementation defined pragmas and such.
>> 
>> Customer response to the language standard? Are you joking?
> 
> Response to experimental features such as pragma Assert; contracts
> specified with pragma Precondition and such; or conditional
> expressions, I think.

All three represent language design bugs, what was the point?

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