From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,19924f2facf8443 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news4.google.com!feeder.news-service.com!feeder4.cambrium.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng1.kpn.DE!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Sat, 09 Aug 2008 09:44:55 +0200 From: Georg Bauhaus Reply-To: rm.tsoh+bauhaus@maps.futureapps.de User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Larger matrices References: <40ed91c2-3dab-4994-9a7b-4032058f0671@56g2000hsm.googlegroups.com> <9cabee20-877a-4fdc-80f8-7746879331da@8g2000hse.googlegroups.com> <489a9675$0$20718$9b4e6d93@newsspool4.arcor-online.net> <75a339dd-969b-4c7a-8e89-7b640171bc2f@e53g2000hsa.googlegroups.com> <13426f2d-0060-47f0-8139-09506383f648@e53g2000hsa.googlegroups.com> <489c2f68$0$1060$9b4e6d93@newsspool3.arcor-online.net> <489c542e$0$12944$9b4e6d93@newsspool2.arcor-online.net> <1d0ueuhuo8z2e.ewzvifms2lau$.dlg@40tude.net> <489c68e1$0$12941$9b4e6d93@newsspool2.arcor-online.net> <1ernhelikct1f$.phk7n6xktz5h.dlg@40tude.net> <489c844b$0$12953$9b4e6d93@newsspool2.arcor-online.net> <1xouarvkb0dop.d7igbk8rqak2.dlg@40tude.net> In-Reply-To: <1xouarvkb0dop.d7igbk8rqak2.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <489d4afc$0$11736$9b4e6d93@newsspool1.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 09 Aug 2008 09:45:00 CEST NNTP-Posting-Host: e2c41ed6.newsspool1.arcor-online.net X-Trace: DXC=XU`eao4Fo<]lROoR14nDHegD_]R5@>3N6J:;Lb7A:ho7QcPOV3C@@Bb\Ed]7:[Db^UCKn\]? X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:1576 Date: 2008-08-09T09:45:00+02:00 List-Id: 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.