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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,70414f56d810c10c X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Received: by 10.68.38.38 with SMTP id d6mr40237735pbk.4.1317404421656; Fri, 30 Sep 2011 10:40:21 -0700 (PDT) Path: lh7ni8440pbb.0!nntp.google.com!news1.google.com!goblin3!goblin1!goblin.stu.neva.ru!noris.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Fri, 30 Sep 2011 19:40:01 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: discriminant questions References: <9f37b726-d80b-4d24-bf3f-28a14255f7fd@s20g2000yql.googlegroups.com> <1tpl2pc36ptr4$.txv4v3wmkjlm.dlg@40tude.net> <1malv6h6q31j3.uz9ws5j0glnm.dlg@40tude.net> <4e81a2f4$0$7624$9b4e6d93@newsspool1.arcor-online.net> <4e81e788$0$6542$9b4e6d93@newsspool4.arcor-online.net> <4e8210ab$0$6550$9b4e6d93@newsspool4.arcor-online.net> <4e83b568$0$7620$9b4e6d93@newsspool1.arcor-online.net> <1vb9afcggqs8b$.prrlzbnf51p$.dlg@40tude.net> <4e8594fa$0$6629$9b4e6d93@newsspool2.arcor-online.net> <1kjj3jgps8ka0$.19lhxt8t7ip2t.dlg@40tude.net> In-Reply-To: <1kjj3jgps8ka0$.19lhxt8t7ip2t.dlg@40tude.net> Message-ID: <4e85fef2$0$6548$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 30 Sep 2011 19:40:02 CEST NNTP-Posting-Host: 62098817.newsspool4.arcor-online.net X-Trace: DXC=Wl;aHCIkbeP5TOT9_N5iZLh>_cHTX3j]W;5Ob_@MI`S X-Complaints-To: usenet-abuse@arcor.de Xref: news1.google.com comp.lang.ada:18241 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: 2011-09-30T19:40:02+02:00 List-Id: On 30.09.11 14:38, Dmitry A. Kazakov wrote: > On Fri, 30 Sep 2011 12:07:53 +0200, Georg Bauhaus wrote: > >> Back on track: my question was whether or not a language should >> enable programmers to implement or override what is built into the >> language core. > > It should not. Aha! >> Whether or not programmers should be able to correctly manipulate >> language features. > > They should not. So that's a no. Then: >> Should a language like Prolog be defined such that (...) >> replace the backtracking implementation with one of their own? > Yes, if Prolog designers wished it survive... but they didn't. And that's a yes. Can the contradiction be resolved? The example about Prolog and its struggle for existence would emphasize my point. The example would show one way in which compiler making and language making are not independent in some situations. The aspect being that economic rationality would suggest programmer-defined language built-ins. (If it sells, ...) > I bet that practically no program uses the number -435167342. Is it not > general purpose? It is not, if no purpose can be specified, and I suppose that few language standards talk about the number -435167342. (Maybe the telephone directory of Eckernf�rde does :-) Numeric types will more likely match general purpose. Anyway, a language standard may define a set of operations, such as Sqrt, and say that they are available in the core language. Array concatenation is one such operation, Sqrt isn't. >> I'll also prefer "task" to mean something that Ada programmers would >> recognize. > > As something, which is not a task? > > I don't understand what you are trying to say. Task is fundamental to > concurrent computing, they cannot be expressed in any other terms. The notion of Ada tasks is a composite notion. A task has ... A task operates this way [sequence of conceptual steps] ... A task type is ... Hence, seen as a notion, a task is not atomic. Typical facilities of an Ada task can be built from other primitives of concurrent programming, if one were to do this in another language. Compiler writer must do this. For programmers, Ada has much of it in the language, Java programmers will find little in the language, but a fair bit in java.util.concurrent.*, i.e. a library. And the necessary discipline. Coming back to the selection of built-ins for a language, communicating tasks are an important building block. The importance is reflected in its special presence in Ada, the language. It has special syntax. Ada tasks do not come from some library. Since the Ada notion of task incorporates many facilities that can be taken for granted, I call tasks heavy, in this sense. Since we have protected objects, sometimes qualified to be light weight, there must have been another notion of "heavy" associated with task. (I.e., in another sense.) >> Plus: 4) compiler making business requirements, > Irrelevant. Practically, compiler making business is rather decisive. Just look at who is active on behalf of the ARG; Google is paying ... for Python, Go ..., MS is paying ... for language research (including standardized languages like C++ or Javascript), the WGs being staffed by ... >> 5) programmers, customers, > Programmers /= customers Yes. > Anyway, you didn't answer which category is supposed to decide what is > "heavy". People from all of the categories try to move decisions in certain directions. That's necessarily my point. To learn about why a feature should go into a language, it takes an interdisciplinary approach, not just because it might be desirable, but because this is what happens as soon as a language starts to have a significant number of users. I should add 6), which is fashion, which sometimes facilitates (and funds!) a language effort in the first place. For example, Douglas Crockford has commented on the pressure that Microsoft (and others?) are exercising on the development process of Javascript. They want the language such that their other languages would have a better backend (i.e. Javascript being the target language). >> A general purpose programming language will IMHO either >> be a panacea that includes, in its definition, every mechanism ever >> invented, > That would be just a poorly designed language. OK >> or tries to be minimal in some sense. > > This applies to *any* language. Being minimal applies to any language only if one trivializes "minimal in some sense", which is a trap. The "some sense" part is the interesting part. >> Alternatively, the customer/programmer can just have >> a Prolog shop make an implementation the meets their special requirements. > > See above. It didn't work in 60s, It works for some of the Ada business now, if I'm not mistaken. A nice thing is that programmers can still write core Ada by the book and talk to the compiler guys about what their run-time should do.