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,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.58.111.202 with SMTP id ik10mr9809305veb.4.1396278813865;
        Mon, 31 Mar 2014 08:13:33 -0700 (PDT)
X-Received: by 10.182.241.70 with SMTP id wg6mr586625obc.19.1396278813755;
 Mon, 31 Mar 2014 08:13:33 -0700 (PDT)
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!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!w5no10424886qac.0!news-out.google.com!gi6ni59igc.0!nntp.google.com!ur14no1155455igb.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 31 Mar 2014 08:13:33 -0700 (PDT)
In-Reply-To: <1396209566.14855.1.camel@pascal.home.net>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=212.191.65.1;
 posting-account=fc1UmgoAAADREbhuD8e4smj7nsEdRFz9
NNTP-Posting-Host: 212.191.65.1
References: <7f1c01c5-3563-4b94-9831-152dbbf2ecdc@googlegroups.com>
 <f188948a-6d8a-4888-80f1-d337a9b6558e@googlegroups.com>
 <1396206120.12713.8.camel@pascal.home.net>
 <1rmd466o46wkh$.xv2pypcsl4nb.dlg@40tude.net>
 <1396209566.14855.1.camel@pascal.home.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <25d23e5d-f9e2-49f1-9c25-9f442042e268@googlegroups.com>
Subject: Re: Your wish list for Ada 202X
From: Stoik <staszek.goldstein@gmail.com>
Injection-Date: Mon, 31 Mar 2014 15:13:33 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 4999
X-Received-Body-CRC: 3606436104
Xref: news.eternal-september.org comp.lang.ada:19059
Date: 2014-03-31T08:13:33-07:00
List-Id: <comp.lang.ada>

W dniu niedziela, 30 marca 2014 21:59:26 UTC+2 u=C5=BCytkownik Pascal Obry =
napisa=C5=82:
> Le dimanche 30 mars 2014 =C3=A0 21:33 +0200, Dmitry A. Kazakov a =C3=A9cr=
it :=20
>=20
> I did such things, it is not so simple.
>=20
> >=20
>=20
> Sure!
>=20
>=20
>=20
> You need a set of "seed" functions to produce initial Formatted_String,
>=20
> > e.g.
>=20
> >=20
>=20
> >    function "&" (L, R : Character) return Formatted_String;
>=20
> >    function "&" (L : Character; R : Integer) return Formatted_String;
>=20
> >    ...
>=20
> >=20
>=20
> No since you always start with the Formatted_String (not derived from
>=20
> string). We need at least a function to create the formatted_string from
>=20
> a string:
>=20
>=20
>=20
>    function "+" (Format : in String) return Formatted_String;
>=20
>=20
>=20
> Then:
>=20
>=20
>=20
>    +"%c" & var
>=20
>=20
>=20
> Or you have to use Empty_Formatted_String constant in each expression.
>=20
> >=20
>=20
> > Another consideration is efficiency, as it would keep on copying the
>=20
> string
>=20
> > upon each concatenation.
>=20
> >=20
>=20
> Copies should be avoided by using a reference semantic. Note that I have
>=20
> declared Formatted_String as:
>=20
>=20
>=20
>    type Formatted_String is private;
>=20
>=20
>=20
> Maybe it should be a tagged type.
>=20
>=20
>=20
> This type is a record with the format. The result (Unbounded_String?)
>=20
> and an index to the current format. That's what I'm thinking.
>=20
>=20
>=20
> Let's say we have:
>=20
>=20
>=20
>    type Formatted_String is record
>=20
>       Format : Unbounded_String;
>=20
>       Index  : Positive;
>=20
>       Result : Unbounded_String;
>=20
>    end record;
>=20
>=20
>=20
> Then
>=20
>=20
>=20
>    +"%c %c"
>=20
>=20
>=20
> Set such record to ("%c %c", 1, "")
>=20
>=20
>=20
> Then with : & Var
>=20
>=20
>=20
> If Var is not a character =3D> raise exception
>=20
>=20
>=20
> Let's say Var :=3D 'x'
>=20
>=20
>=20
> If a char then the record becomes : ("%c %c", 3, "x")
>=20
>=20
>=20
> That's how I would do such implementation.
>=20
>=20
>=20
>=20
>=20
> --=20
>=20
>   Pascal Obry /  Magny Les Hameaux (78)
>=20
>=20
>=20
>   The best way to travel is by means of imagination
>=20
>=20
>=20
>   http://v2p.fr.eu.org
>=20
>   http://www.obry.net
>=20
>=20
>=20
>   gpg --keyserver keys.gnupg.net --recv-key F949BD3B

A clever use of & and + makes it possible to output complicated mixtures of=
 elements of various types, so it seems that nothing needs to be added to t=
he language (unless we have an elegant way of adding an "input" and "output=
" aspect to the type). On the other hand, there is clearly a need for one o=
r more subprograms for the input of strings. Just now, we have three fairly=
 convenient ways of inputing a line: procedure get_line (with the inconveni=
ence of an additional parameter and the necessity of guessing the maximal l=
ength of the string), function get_line returning string (one usually needs=
 to add a block to use it) or get_line returning unbounded_string (very con=
venient, may be not so efficient). What is needed are subprograms for enter=
ing a word (get_word) delimited by default by spaces. This is what cin from=
 C++ does. All methods I know of (not requiring me to write the subprograms=
) is to enter the whole line and then to chop it, using either subprograms =
from GNAT library, or things like find_token, slice and delete. Getting a w=
ord from the input is so ubiquitous, that one should be able to do it very =
easily.