From: Georg Bauhaus on
Dmitry A. Kazakov wrote:

> Synchronization mechanisms of higher level than Ada? I am excited. You mean
> semaphores, I bet.

I don't mean semaphores. You bet.
And I said, have tasking offered with much higher level PLs.
That said, is there any direct reflection of the theory of channels
in Ada?
Is pragma No_Return a high level solution for "possibly dying
remote computation"?
Look at how they currently work around distributed tasking as criticized
by Liskov many years ago: It seems to have become a more pressing
issue-- or can be bought and sold, at least.



>> There is no EVAL or COMPILE in Ada.
>
> Assembler has them.

Assembly language does not, of course, *have* EVAL or COMPILE
instructions. Sure, you can GOTO EVAL, and have self modifying
code at random. That's always interesting, but I'm sure it doesn't
convince people that assembly language is therefore high level.


>> There is no goal directed evaluation.
>
> I saw this term only in the context of low-level image processing
> primitives. Sorry, it rings wrong bells.

The goal finding operators, e.g. assignment, of a language execute
until the expression delivers a value suitable in context (the goal
is met).
The expression involves the same type of operators, recursively.
You can make your own. Example language is Icon.
So it has backtracking built in at the expression level, i.e. not at the
roll your own level.


>> There is no function environment (no upward closures).
>
> Procedural composition is itself low-level. Ada need not to worry about
> that low-level stuff.

O.k, function composition is not the same as a some kind of type
composition that includes the primitive opearations.
Sure. That is a different tree, does only grow on Qi land
or on some recent extension of Haskell.

(I'd say that functionalists tend to fall victim to what
they call "fusion". Many also happily ignore controlling digital
computers. But they call the laws of functional composition high
level, as everyone else does.)


>> There are no generators with suspension.
>
> Hydropneumatic suspension? Sorry.

suspend/resume on expressions. Helps with non-deterministic or
arbitrary length data structures, execute on demand (lazy), etc.
You can program this in Ada by roll-your-own.


>> There is no symbol manipulation, no expression macros, no inference.
>
> Symbol manipulation is text processing, no problem in Ada. Macros is
> low-level source text processing. We don't need that.

The point is, you can do things with Lisp macros the you cannot
do otherwise. Are you saying that because you can do without the
power of a Lisp macro system in your programs, these macros must
therefore be part of low level languages for everyone else?


> Elaborated inference is inconsistent with maintainability if not low-level.
> Namely, if inferred things are understandable, they are trivial. If they
> are non-trivial (as in Prolog), then nobody can predict the program's
> behavior.

Well, you do not *want* to predict the program's behavior.
You want to see possible solutions, that's all.


>> There are no solvers.
>
> Because Ada programs solve non-trivial problems. Anyway, declarative is not
> a synonym of higher level.

"Declarative" may be hyped, but by all definitions I know,
"declarative" certainly fits "higher level". Anyway, you can
combine solvers to solve non-trivial problems using combination
operators, where each solver contributes to the solution.
No Ada style roll-your-own-solvers involved.

Another example: Throw a problem decomposition into the tuple space and
wait for it to solve the problem in some way. Maybe stepwise.


>> There are no graphics primitives etc..
>
> Turtle graphics must be of an extremely high level...

To me graphics primitives seem higher level than a load of
Bitmap_View.Set_Pixel(Our_Turtle.Next_Y,
Our_Turtle.Next_X, Color => Red);

I want to be able to say, "draw a bar chart using this set of data",
*without* programming.
Using R, to pick an approximation to high level graphics operators,
it is exactly what I do, *without* further graphics systems programming.
That's high level. (And, BTW, applicable in many domains.)


> You are making an error equating domain-specific to high level.

Like the rest of humanity continues to err by using more or less
established language. :-)

Almost all programming tasks *are* domain-specific.
High level operators from high level language just
ease the construction of many domain-specific programs. That is,
of almost all programs. At the cost of lesser control of the hardware.
No systems programming style involved when computing "Vec . Vec"
in a high level language that supports arrays at a higher level
than does Ada.
Systems programmers revert to whatever level they can get, ADTs
for a start, and "patterns" for much of the remaining solutions.

I'm *not* saying that there is anything inherently superior in
using higher level operators and such!
Array operators are just operating at a higher level than single
array cell manipulation will do. So, typically, Ada programmers
with rely on a call to some roll-your-own "*" for arrays.

If I had wanted to say, "high level type system", where high level
refers to properties such as thread of control, the order of
possible calls established by the acceptor protocol, and so on,
I had said so.


> It is
> usually reverse. Domain-specific languages are of very low level, because
> they translate straightforwardly into the engine, which plays the role of
> the hardware. This is low-level.

This is just two solution layers close to each other, and both at a high
level. By a not uncommon definition, at least. If I say,
Result <- M1 {times} M2
and the parallel vector APL engine translates this into a smart
distributed algorithm, and the result arrives within time bounds,
and the operator {times} with all the magic is *builtin*, and
is portable, and adapts to the execution environment, I call that
high level.

> Describe a set of tables sharing some property in SQL.

A high level PL expression would be

"make X persist",

provided this expression alone achieves persistence *without*
further programming.
No database systems programming needed such as invoking SOCI,
ODBC, writing a user defined ADT for Embedded Snorkle or whatever.



> In terms of abstraction level, most of domain-specific languages stop where
> FORTRAN-IV began. That's why there is no 5GL, 6GL, 7GL... The idea was
> wrong.

So their idea was wrong (where the 5GL is usually though of as logic
and constraints), yours are right? Might be, but could you please chose
a good set of fresh words and avoid speaking of "high level languages"
when you are referring to something else?


>> Use a language that allows you to say,
>> using *builtin* operators, things like
>>
>> "Give me all blocks of neighbours no more than two edges apart."
>>
>> That's high level.
>
> procedure Give_Me_All_Blocks...;
>
> This is not high level, and I know the price.

Exactly, the Ada example is lower level, and requires
an implementation subprogram.
Ada doesn't offer the high level given in the phrase above.


> Domain-specific languages are
> usable in domain-specific cases ... and unusable universally.

Most high-level languages are demonstrably usable universally.
They need not be restricted to specific cases in some domain.
And certainly, SQL is not representative of the higher level languages.


From: Dmitry A. Kazakov on
On Sat, 09 Aug 2008 09:44:55 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
>
> That said, is there any direct reflection of the theory of channels
> in Ada?

Channel is high level? Come on.

> Is pragma No_Return a high level solution for "possibly dying
> remote computation"?

RPC is low-level, but it is a different issue. Concurrent /= remote
computing.

> Look at how they currently work around distributed tasking as criticized
> by Liskov many years ago: It seems to have become a more pressing
> issue-- or can be bought and sold, at least.

Where are those higher level abstractions of tasking?

>>> There is no EVAL or COMPILE in Ada.
>>
>> Assembler has them.
>
> Assembly language does not, of course, *have* EVAL or COMPILE
> instructions.

MOV @-(PC), @-(PC)

if I correctly remember PDP-11. It writes itself into the memory before the
current instruction and then executes it. How extremely high level!

Look, it is not a programming paradigm, like reflection in this case, which
makes it low or high level, but the way of composition.

>>> There is no goal directed evaluation.
>>
>> I saw this term only in the context of low-level image processing
>> primitives. Sorry, it rings wrong bells.
>
> The goal finding operators, e.g. assignment, of a language execute
> until the expression delivers a value suitable in context (the goal
> is met).

This is not high level it is iteration. See above.

It could be high level if the language provided a framework for composition
conditions, goals and iterative tasks. Declarative languages are notably
weak in that respect.

> (I'd say that functionalists tend to fall victim to what
> they call "fusion". Many also happily ignore controlling digital
> computers. But they call the laws of functional composition high
> level, as everyone else does.)

"High" sounds better than "low"...

>>> There are no generators with suspension.
>>
>> Hydropneumatic suspension? Sorry.
>
> suspend/resume on expressions. Helps with non-deterministic or
> arbitrary length data structures, execute on demand (lazy), etc.

So again, lazy becomes a substitute for high. Why? What if I proclaim that
eager evaluation is high? What if the language, like Ada, does not specify
eagerness in many cases? Which is BTW is high level, because it abstracts
away an irrelevant to the semantics aspect of evaluation.

>>> There is no symbol manipulation, no expression macros, no inference.
>>
>> Symbol manipulation is text processing, no problem in Ada. Macros is
>> low-level source text processing. We don't need that.
>
> The point is, you can do things with Lisp macros the you cannot
> do otherwise.

An industrial Ada compiler written in Lisp? Come on.

> Are you saying that because you can do without the
> power of a Lisp macro system in your programs, these macros must
> therefore be part of low level languages for everyone else?

No, I am saying that macro has to be a part of no language.

>> Elaborated inference is inconsistent with maintainability if not low-level.
>> Namely, if inferred things are understandable, they are trivial. If they
>> are non-trivial (as in Prolog), then nobody can predict the program's
>> behavior.
>
> Well, you do not *want* to predict the program's behavior.
> You want to see possible solutions, that's all.

If I cannot predict it, how do I know that these are solutions? But the
aircraft hitting the ground is certainly a possible solution of flight
equations. Do you want to see it, before you jump off?

>>> There are no solvers.
>>
>> Because Ada programs solve non-trivial problems. Anyway, declarative is not
>> a synonym of higher level.
>
> "Declarative" may be hyped, but by all definitions I know,
> "declarative" certainly fits "higher level".

Higher than what?

> Anyway, you can
> combine solvers to solve non-trivial problems using combination
> operators, where each solver contributes to the solution.

That is what I want to see, the means of composition of declarative
descriptions. Consider these:

1: x**a + y**b = z**c
2: a = b = c
3: a in natural

Go on!

> No Ada style roll-your-own-solvers involved.

Even if provided as a library package?

> Another example: Throw a problem decomposition into the tuple space and
> wait for it to solve the problem in some way. Maybe stepwise.

Yep, a problem like HALT(p).

Again, high level is not about the semantics of the primitive operations.
As the name suggests, a primitive operation is primitive, even if it took
millions of man-years to implement, like the MOV instruction of a modern
processor.

>>> There are no graphics primitives etc..
>>
>> Turtle graphics must be of an extremely high level...
>
> To me graphics primitives seem higher level than a load of
> Bitmap_View.Set_Pixel(Our_Turtle.Next_Y,
> Our_Turtle.Next_X, Color => Red);

But Set_Pixel *is* a graphic primitive. Why is it low-level then? I thought
your point was that everything about graphics were high level. If not, then
we must talk about what makes a graphics framework high or low level.

> I want to be able to say, "draw a bar chart using this set of data",
> *without* programming.

Which set of data? How data are composed? How the bar interacts with other
graphical objects?

Draw a bar is a *low*-level rendering command. Worse than that, it is
imperative. How awful...

>> You are making an error equating domain-specific to high level.
>
> Like the rest of humanity continues to err by using more or less
> established language. :-)

Ah, there are so many errors "the rest of humanity" is accustomed to do,
that this one would not make any change. After all that rest uses C++...
(:-))

> High level operators from high level language just
> ease the construction of many domain-specific programs. That is,
> of almost all programs.

Nope. If it were true, there would be no need to program anything.

>> It is
>> usually reverse. Domain-specific languages are of very low level, because
>> they translate straightforwardly into the engine, which plays the role of
>> the hardware. This is low-level.
>
> This is just two solution layers close to each other, and both at a high
> level. By a not uncommon definition, at least. If I say,
> Result <- M1 {times} M2
> and the parallel vector APL engine translates this into a smart
> distributed algorithm, and the result arrives within time bounds,
> and the operator {times} with all the magic is *builtin*, and
> is portable, and adapts to the execution environment, I call that
> high level.

And it is not, because you are already at that level. It is not higher, it
is same. Higher level describes an ability to compose abstractions higher
than the granted ones. A solution always requires layered abstractions over
the domain:

Solution -----------------------------------
| S1 | D1 | U1
| | |
Domain | |
abstraction <--> Domain-specific <--->|
language | U2
| |
| D2 Universal language
| | U3
| |
Hardware abstraction, when same

Yes a universal language has abstraction difference U2, usually covered by
a set of reusable libraries. But the reason why domain-specific languages
never made it is that D1 >> U1 for any more or less realistic S1.
Abstractions aren't additive. This is why such languages are lower-level
(D1 >> U1). They require much bigger amount of work in order to bridge S1.

Furthermore, large systems deal with many domains, so the language
impedance eats that smallness which could be left over. In fact, more than
half of human and computational resources are spent on fighting the
shortcomings of domain-specific languages and libraries.

>> Describe a set of tables sharing some property in SQL.
>
> A high level PL expression would be
>
> "make X persist",

This is not SQL. So you agree with me that SQL is low-level.

>> In terms of abstraction level, most of domain-specific languages stop where
>> FORTRAN-IV began. That's why there is no 5GL, 6GL, 7GL... The idea was
>> wrong.
>
> So their idea was wrong (where the 5GL is usually though of as logic
> and constraints), yours are right? Might be, but could you please chose
> a good set of fresh words and avoid speaking of "high level languages"
> when you are referring to something else?

But n in nGL is the number of a languages generation. Where it follows from
that n1 > n2 => L1 is higher level than L2? It probably was hoped in to
happen, magically, but it did not.

>>> Use a language that allows you to say,
>>> using *builtin* operators, things like
>>>
>>> "Give me all blocks of neighbours no more than two edges apart."
>>>
>>> That's high level.
>>
>> procedure Give_Me_All_Blocks...;
>>
>> This is not high level, and I know the price.
>
> Exactly, the Ada example is lower level, and requires
> an implementation subprogram.

Why do you care if it was not you who wrote it? Again, higher level
language provides an open-end way to build up reusable components. This is
what Ada and other popular universal languages like C++ can extremely well.
Domain-specific languages fail here miserably.

> Ada doesn't offer the high level given in the phrase above.

But it could. [Language in the theory of formal languages is equivalent to
the set of all possible programs of.]

The problem with the domain-specific languages is their incompleteness in
practice, even when a particular language is technically Turing-complete.

>> Domain-specific languages are
>> usable in domain-specific cases ... and unusable universally.
>
> Most high-level languages are demonstrably usable universally.
> They need not be restricted to specific cases in some domain.
> And certainly, SQL is not representative of the higher level languages.

Oh, write an Ada compiler in Prolog. It must be that simple, or?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: amado.alves on
Thanks to all.
I have succeeded by increasing the stack size of a subtask to 1G!

task type Subtask_T;
for Subtask_T'Storage_Size use 1_000_000_000;
task body Subtask_T is
begin
Main;
end;

This compiles and runs on GNAT on Windows sans any extra pragma or
option.
It processes the 5000 x 5000 matrix (multiplication by a vector).

I tried 200M first for the Storage_Size. Not enough. Don't know why.
5000 x 5000 << 200M. BTW the semantical maximum is Integer'Last.

On Mac OS X I simply cannot run multitasks.
From: Peter C. Chapin on
amado.alves(a)gmail.com wrote:

> I tried 200M first for the Storage_Size. Not enough. Don't know why.
> 5000 x 5000 << 200M. BTW the semantical maximum is Integer'Last.

5000 x 5000 = 25 million. But then how large is each matrix element? If
each element is 8 bytes your matrix is exactly 200 MB in size.

Peter
From: amado.alves on
> 5000 x 5000 = 25 million. But then how large is each matrix element? If
> each element is 8 bytes your matrix is exactly 200 MB in size.

My real type has 10 digits. Don't know how many bytes. I guessed 4,
but maybe it's 8. Curiously enough a storage size explicitly set by
the expression 5000 * 5000 * Real_Type'Size, theoretically only enough
for the matrix, works! (I would expect more space to be required e.g.
for the vector.)

But in sum I am very happy now with my GNAT GPL 2008 on Windows Vista
Basic configuration :-)