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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,7b5615402713dcbb
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.180.88.195 with SMTP id bi3mr2329473wib.3.1346151041262;
        Tue, 28 Aug 2012 03:50:41 -0700 (PDT)
Path: 
 q11ni356884408wiw.1!nntp.google.com!goblin3!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Brian Drummond <brian@shapes.demon.co.uk>
Newsgroups: comp.lang.ada
Subject: Re: Ada and Java/C++
Date: Tue, 28 Aug 2012 10:50:40 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <k1i7q0$4oa$2@dont-email.me>
References: <8bfbf709-18ac-43cd-b037-ce47adde96c2@googlegroups.com>
	<1dy5xgqtdqpp6$.qio4t8fjk8b5.dlg@40tude.net>
	<513d6efb-6aad-4013-8b21-37c75aa6aaf7@googlegroups.com>
	<k1gv4k$52m$1@munin.nbi.dk>
	<b5ae2953-1c55-4768-add4-75af019c0e98@googlegroups.com>
Mime-Version: 1.0
Injection-Date: Tue, 28 Aug 2012 10:50:40 +0000 (UTC)
Injection-Info: mx04.eternal-september.org;
 posting-host="0e44dd4a3c4e0a6e83a86f947fb780ae";
	logging-data="4874"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18pAX7K+x9eDWeRh4TRbfd78aPn2AqF2DY="
User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT
	30dc37b master)
Cancel-Lock: sha1:Ue85VSeMx70WF9h9Bx0TFwQwihA=
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Date: 2012-08-28T10:50:40+00:00
List-Id: <comp.lang.ada>

On Mon, 27 Aug 2012 19:14:39 -0700, Adam Beneschan wrote:

> On Monday, August 27, 2012 4:16:39 PM UTC-7, Randy Brukardt wrote:
> 
>> I agree with you here (but also see below). But the syntax of a
>> language is a very important part of the foundation of the language.
>> Ada's syntax is designed to minimize the possibility for inadvertant
>> errors, which is not the case with the C syntax. 

> Hmmm ... I guess it depends on just how much of the syntax the OP is
> thinking of keeping.  I'd think that if we're just talking about the
> "look and feel", one could probably develop a language that has the
> functionality of Ada but using C-like keywords and operators, without
> compromising safety.  

I suspect you are onto something here ... I believe the OP meant not the 
syntax, but the lexical level of the language. A lot of the "feel" of a 
page of source comes from the tokens used, rather than the order of their 
arrangement. 

Changing begin and end to { and } does not change the syntax a jot*, but 
makes the language look a lot more like C. And I suspect THAT is what the 
OP intended. 
(I appreciate that would leave a lot of work around things like 
conditional statements, to make them "look right" while preserving their 
syntactic advantages. But bear with me...)

Perhaps it could be run through a simple macro preprocessor and turned 
into Ada.

> I'm not saying it's a good idea. Personally, if
> someone sent me a compiler for a language like that, I wouldn't just
> delete it from my system, I'd print it out just so that I could run it
> through a shredder and then stomp on it.
> 
> But some changes, like using [] instead of () for array indices or { }
> instead of begin/end or expressing type conversions as (type)expression
> instead of type(expression), wouldn't seem to have any negative impacts
> on safety.  (Just on aesthetics.)  

And refactoring, when you substitute evaluation for lookup, or vice versa.

> The point is that if the OP's premise is correct--that Java is popular
> because it borrows from C syntax even though it eliminated some of the
> unsafe and error-prone things from the language, then in theory, a
> mutant Ada language with C-like syntax could do the same.  If I were
> induced by a very large sum of money to help develop such a language,
> I'd want to make some changes like (1) making assignment statements
> statements rather than expressions, ...

While agreeing with your list, I would go further and simply keep Ada's 
syntax largely intact*; restricting the changes to what can be 
accomplished at the lexical analysis stage.

* I don't see that transforming "a += b" into "a := a + b" etc would 
break this model...

- Brian