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,b076e6315fd62dc5
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.68.191.225 with SMTP id hb1mr14270944pbc.5.1338418836193;
        Wed, 30 May 2012 16:00:36 -0700 (PDT)
Path: 
 l9ni1524pbj.0!nntp.google.com!news1.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.musoftware.de!wum.musoftware.de!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: BrianG <me@null.email>
Newsgroups: comp.lang.ada
Subject: Re: fyi, very interesting Ada paper OOP vs. Readability
Date: Wed, 30 May 2012 19:00:32 -0400
Organization: A noiseless patient Spider
Message-ID: <jq68qj$de5$1@dont-email.me>
References: <jodq5f$j5f$1@speranza.aioe.org> <jof9dq$c46$1@munin.nbi.dk>
 <m2y5p0sfyg.fsf@pushface.org> <jokbc7$k7p$1@munin.nbi.dk>
 <jq3vh7$6nh$1@dont-email.me> <a2m0hsF38oU1@mid.individual.net>
Mime-Version: 1.0
Injection-Date: Wed, 30 May 2012 23:00:35 +0000 (UTC)
Injection-Info: mx04.eternal-september.org;
 posting-host="5MNoRlpIAhOS/jy0qxZerw";
	logging-data="13765"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/U05IBcLLcYYr6KU2HMEdd"
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16
In-Reply-To: <a2m0hsF38oU1@mid.individual.net>
Cancel-Lock: sha1:fOLT2EpvhWqrCj+IM+eeHQX493I=
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Date: 2012-05-30T19:00:32-04:00
List-Id: <comp.lang.ada>

On 05/30/2012 03:29 AM, Niklas Holsti wrote:
> On 12-05-30 04:09 , BrianG wrote:
>> On 05/11/2012 08:37 PM, Randy Brukardt wrote:
>>> Ada should have had a "conversion" operator ("#" has been proposed), and
>>> clearly Ada.Strings.Unbounded should use it. But that gets shot down
>>> every
>>> time it is proposed (and it has been proposed for every language
>>> revision
>>> other than Ada 2012); mainly because a minority think that "+" is
>>> perfectly
>>> good for that. And another minority think that uses "+" on non-numeric
>>> types
>>> is *disgusting*, so we can never get the operators added to packages. A
>>> perfect impasse.
>>>
>>> Randy.
>> Why not unary "&", isn't that closer to the existing syntax?
>>
>
> Please, not "&", that would make calls look too much like calls in C
> with pointer parameters. "&" being the C "address-of" operator. "&" is
> also a large glyph, as tall as upper-case letters, making a following
> identifier harder to recognize at a glance. How about "~"? Meaning, I
> want "approximately" this value, but converted as necessary.
>
So I guess we should ban 'C' as a variable name too.  Who cares what 
looks like C?  Does that somehow bring along with it the problems in C? 
  How?

We already have A := "This" & " That", Why not also B := &"The other", 
that makes it perfectly analogous with D := 1 + 2 and E := +3.  (Yes, I 
skipped C :-)  Function "&" already has an established meaning in Ada, 
why not use it for a (somewhat) similar purpose?

If that looks like C, you could always use
B := Ada.Strings.Unbounded_String."&"("The Other");  or B := "&"(A);
That doesn't look anything like C.

It sounded from Randy's message, that (some of) the problems were based 
on defining a new operator ("#") and unrelated reuse of an existing 
operator ("+").  This proposal fits in with existing Ada usage.

(Funny, today I was going thru Sun's (Oracle's) Java tutorial, and 
several places they had something like "+ is used for addition, and oh 
by the way, also for string concatenation".)

-- 
---
BrianG
000
@[Google's email domain]
.com