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=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!newsfeed0.kamp.net!newsfeed.kamp.net!news-feed.eu.lambdanet.net!news.pop-hannover.net!news-feed.cs.net.de!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Sun, 15 Jun 2014 12:04:26 +0200
From: Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: a new language, designed for safety !
References: <lmj8s6$hhp$1@speranza.aioe.org>
 <1402308235.2520.153.camel@pascal.home.net> <85ioo9yukk.fsf@stephe-leake.org>
 <e41c64cc-af26-4971-9db3-aec0fb4f5893@googlegroups.com>
 <9qednXOIGNDuLQXORVn_vwA@giganews.com>
 <1872904482424209024.314619laguest-archeia.com@nntp.aioe.org>
 <GtudnWClAsEmmQTORVn_vwA@giganews.com>
 <e3b1435a-499a-43b1-a7b7-6ee03167183f@googlegroups.com>
 <wrKdnYYvD8xzEATORVn_vwA@giganews.com>
 <810507a4-427e-42bb-a468-e5939a4470db@googlegroups.com>
 <lnd8l7$h89$1@dont-email.me> <9qbfr6yf0gnb.182y1qs9eigz4$.dlg@40tude.net>
 <b0db3175-85d4-4c66-a6de-9fd68de7e5b3@googlegroups.com>
 <1lk5etrvv7sy2$.p7h015lw2pmn$.dlg@40tude.net>
In-Reply-To: <1lk5etrvv7sy2$.p7h015lw2pmn$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <539d6faa$0$6670$9b4e6d93@newsspool3.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 15 Jun 2014 12:04:27 CEST
NNTP-Posting-Host: f02746b6.newsspool3.arcor-online.net
X-Trace: 
 DXC=m[WWkTh>?SeeoCI^f\Y]EaMcF=Q^Z^V3h4Fo<]lROoRa8kF<OcfhCOkB_QmXYGIhNhPCY\c7>ejVhTN]iG38:H<cnRLNd`]YE4c
X-Complaints-To: usenet-abuse@arcor.de
Xref: news.eternal-september.org comp.lang.ada:20314
Date: 2014-06-15T12:04:27+02:00
List-Id: <comp.lang.ada>

On 15/06/14 08:52, Dmitry A. Kazakov wrote:
>> >Oh, dynamic memory is the same in this aspect. Should it be in the
>> >language or in the library?
> In the library. Ada 95 introduced storage pools for exactly this purpose.

But moving (backing) operators to (by) the library should not entail
abandoning special  syntax, I would hope?

Otherwise, libraries will offer nothing but a bag of names (of
types and their operations, say), blurring distinctions that
facilitate expressing "typical patterns" of program structure,
discernably.

Imagine a programmer wishing to express a typical pattern such as

   "Find A in B!"

And imagine a language framework for integrating this pattern with
other language features:

* the first A in B
* the number of A in B
* all A in B
* while there is A in B ...
* is there A in B such that ...

All of these cases should not be part of differently named procedures,
or depend on optional presence of differently named parameters. The
pattern is "generic". Instead, all use cases might be inferred from
context, as is done by the Icon programming language, or, to some
extent, in Python, and in Ada's new loop syntax, if one twists the
argument a little. (Or, in GNAT's Spitbol patterns, taking
backtracking into account.)

Can we have these "program patterns" via syntax and operators?
Even when a compiler needs to make sure that a library based
"interpretation" is consistent with the Ada LRM?

Operators in (syntactical) context will add readability because
the pattern is clear, not because one knows some names.

Just names would result in only trivial readability. A programmer
would need to have received special training in names (vocabulary)
since the meaning of those names for special program patterns is
hidden behind non-special words, they would not be obvious.(*)

__
(*) "Just names" can create a costly mess. The plethora of operations
on strings that involve {index, indexOf, find, substr, substring, ...}
demonstrates, their meanings and arguments being sometimes alike,
sometimes different, and per language. The Javascript language has both
substr *and* substring. They differ.