Re: discriminant questions

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

On 27.09.11 14:14, Dmitry A. Kazakov wrote:
> On Tue, 27 Sep 2011 12:18:28 +0200, Georg Bauhaus wrote:
> 
>> On 27.09.11 10:10, Dmitry A. Kazakov wrote:
>>
>>> Consider a type system where your precious kludges of old Ada would become
>>> some type expressions and library implementations rather than built-in
>>> stuff.
>>
>> In the opposite direction, an alternative effort would set out
>> to find language for the field tested patterns hidden in libraries.
> 
> No the opposite direction is to have built-in "patterns". 

That's what I meant to say; to design some language for those "patterns"
being now "emulated" in libraries seems harder.  Harder because you need
to decide that (1) This is it! and (2) Though shalt not be a language
designer, but a programmer.  Even when you write reusable libraries.
These built-ins might be harder for compiler makers to implement, IIUC.

A use case:

  "Run these independent procedures concurrently.  They share
   one variable."

With a normal, practical programmer in mind, a typical "pattern"
of language extension into the domain of concurrency is to enable
writing, in pseudo code:

   concurrent procedure one (a, b: input; c: out output) is
   begin
      ...
      lock shared.do(b, 42) end lock;
      ...
   end;

This reuses the notion of "procedure", the word "concurrent" being a hint,
the lock being automatic; critical region isolated, perfectly easy!
(If lousy, but quality issues needs to be addressed with care.)
Now in Ada, they tell you to write a task,

   task one is
   begin
     ...

(interrupting) "Where do I put a, b, and c?"  "In entries, moment please!"
... "Oh, gosh, more mechanism, why can't it be easy?"  "OK, wait:

   task worker is
   begin
     one (a, b, c);
   end;

Does this look easy?" "OK, where do a, b, c come from?"  "You make
them visible, the task could be local :

   procedure one
       (a, b: input;
        c: output)
   is
       task worker is
       begin
           ...
       end;
   begin
       null;
   end;"

"OK (boring, verbose, so many ways), how about the shared variable?"
"Just define a protected object."  "What?"

... etc

The increasingly annoyed questioner might be right or wrong
from a software engineering point of view, the language design
will have to address his concerns or else he does not buy.

A library, or a pattern, might seem to help:

  task type Run_Once
    (job : access procedure (a, b: input; c : out output))
  is
     pragma Storage_Size (N);
  end Run_Once;

But when is `c` filled?  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.


> It is also interesting how non-implemented "patterns", and as I understand,
> your desire is to keep them such, could be tested in the field, before
> being incorporated into the language core? Was for example limited type
> return tested in the field? Accessibility rules? Anonymous access types?

At Ada-auth, they usually say something about customer response to
implementation defined pragmas and such. I should hope that new
languages are made the way that matches the way a certain requirements
document was made, reviewed, parts dismissed, reviewed again, compared,
etc.