From: (Hibou57) Yannick Duchêne on
Le Fri, 12 Feb 2010 16:10:19 +0100, Robert A Duff
<bobduff(a)shell01.theworld.com> a écrit:
>>> Extended return statements are not so important for nonlimited types,
>>> but they do come in handy in that case, too.
>> While this may be useful, if it was, to have a way to return none-
>> limited as built-in-place, for efficiency purpose (just suggesting
>> this be to investigated, I do not assert this could surely be done
>> like this and as-is).
>
> Again, extended returns do NOT cause build-in-place.
> For non-limited, the compiler may choose build-in-place
> for efficiency in some cases.
>
> - Bob
It was a suggestion (you seems to really be afraid of this possible
confusion)

--
Test
From: Hibou57 (Yannick Duchêne) on
Le Fri, 12 Feb 2010 19:07:43 +0100, mockturtle <framefritti(a)gmail.com> a
écrit:

> On Feb 12, 5:57 pm, Adam Beneschan <a...(a)irvine.com> wrote:
>>
>> Now that the language requires compilers to allow identifiers
>> containing any character in any alphabet that exists or has ever
>> existed, including ancient languages like Ogham (http://
>> en.wikipedia.org/wiki/Ogham --- seriously, I'm dying to use an
>> Eamhancholl in one of my variable names),
>
> To increase readibility, right? :-)) (sorry, I could not resist)
>
OT: seems the Celts heavily normalized the hash sign 3000 years before the
ASCII does

--
This isn't an oops
From: Hibou57 (Yannick Duchêne) on
Le Sat, 13 Feb 2010 03:00:55 +0100, Randy Brukardt <randy(a)rrsoftware.com>
a écrit:
>> Well, this one makes a little more sense than the aggregate thing.
>> But it doesn't work if you say "Arr(Index) := ..."!
>
> Unless Tucker's latest project works out. Stay tuned...
What's the new Professor Sir Tucker Taft's project ?

--
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just
not lucky
From: Hibou57 (Yannick Duchêne) on
Le Sat, 13 Feb 2010 16:59:44 +0100, Robert A Duff
<bobduff(a)shell01.theworld.com> a écrit:
>> What's the new Professor Sir Tucker Taft's project ?
>
> The ARG is inventing some syntactic sugar to make user-defined
> container code easier to read, and Tucker is doing most of
> the work on that. One example is that there will probably be some
> mechanism to say:
>
> A(X) := A(X) + 1;
>
> where A is (say) a hash table mapping strings to integers,
> and X is a string. User-defined array-indexing notation.
>
> Also, some new kinds of for loops. For example, looping
> through the components of an array without any
> horsing around with index values:
>
> for C : Character of My_String loop
> Do_Something(C);
> end loop;
>
> The ": Character" above is optional, according to the latest proposal.
That's high-level language capability.

So that's to be added with the other project I've heard about here at
comp.lang.ada, about first-class-functions (it was during the thread about
making constant declarations overloadable if my mind is right) and the
pre-post-condition discussed here and on fr.c.l.a.

As Santa Claus seems to be actually checking orders, do you know if there
will be something like co-routines ? We already have tasks, but tasks are
a bit too much heavy as co-routines. I was to open a thread to investigate
this topic two weeks ago (I finally did not start it). I'm thinking about
it, beside another topic about unknown discriminants.

--
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just
not lucky
From: Hibou57 (Yannick Duchêne) on
Le Sun, 14 Feb 2010 11:59:44 +0100, Dmitry A. Kazakov
<mailbox(a)dmitry-kazakov.de> a écrit:
>>> Nope, the mathematical notation for a tuple is as in Ada (a,b,c,...),
>>> so
>>> should it be.
>>
>> Well, none of the following Ada operators use the standard maths
>> notation:
>>
>> - * / ** <= >= /= and or not
>
> Hey, somebody pushed for Unicode in Ada2005. Isn't it time now to fix
> that?
> (:-))
I use to think about this one , using the Unicode characters standing for
this kind of relationship operator and others, but this would not work
anyway in some editor/IDE, like GPS, and the ones looking like ASCII Art
(the actual ones), are easier to input.

--
No-no, this isn't an oops ...or I hope (TM) - Don't blame me... I'm just
not lucky