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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
X-Received: by 2002:ae9:f30f:: with SMTP id
 p15mr22084871qkg.178.1587996609308;
        Mon, 27 Apr 2020 07:10:09 -0700 (PDT)
X-Received: by 2002:a9d:7d15:: with SMTP id
 v21mr18098367otn.182.1587996608837;
 Mon, 27 Apr 2020 07:10:08 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 27 Apr 2020 07:10:08 -0700 (PDT)
In-Reply-To: <r86jep$93r$1@dont-email.me>
Complaints-To: groups-abuse@google.com
Injection-Info: google-groups.googlegroups.com; posting-host=70.109.61.2;
 posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf
NNTP-Posting-Host: 70.109.61.2
References: <ea6d64d1-fb0c-42de-b787-26ccfbccee9b@googlegroups.com>
 <26e971a9-6fcc-4e4c-84ee-d74aecd5b217@googlegroups.com>
 <r838c5$5ts$1@dont-email.me>
 <2c769c87-72f2-4107-b0bf-3846e3ae6c7a@googlegroups.com>
 <r84f7m$20l$1@dont-email.me>
 <670160da-e66d-446f-a415-27df39d9a73f@googlegroups.com>
 <r86jep$93r$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <250c110a-667d-419a-b52a-89646c178d99@googlegroups.com>
Subject: Re: Image attribute (yet again)
From: Jere <jhb.chat@gmail.com>
Injection-Date: Mon, 27 Apr 2020 14:10:09 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Xref: reader01.eternal-september.org comp.lang.ada:58511
Date: 2020-04-27T07:10:08-07:00
List-Id: <comp.lang.ada>

On Monday, April 27, 2020 at 8:33:31 AM UTC-4, J-P. Rosen wrote:
> Le 26/04/2020 =C3=A0 19:33, Jere a =C3=A9crit=C2=A0:
> > I'm not saying it can't be done.  I'm saying by the time I go through
> > all the processing needed, I might as well wrote my own function.  It
> > makes the existing operation mostly useless (unless I just want a=20
> > temporary debug print that I don't care how it looks).  For example,
> > if I want to print to a 16x2 character LCD screen and I want to print
> > 0 padded 4 digit hex values with no "16#" prefix or "#" ending, then
> > I need to call Put with an 8 character string, search for the first
> > occurrence of '#' (it can be in multiple locations), then overwrite
> > a variable number of those characters with 0's (based on the location
> > of '#'), and then extract the 4 digits I actually need.  All doable=20
> > (not saying it cannot be done), but at that point, I am better off=20
> > just doing my own custom operation instead instead of even using the
> > Put operation. =20
>=20
> This feature requires that if you write a number in a certain base, then
> you need to recognize the base when reading. So it's not an error, but a
> design decision. Of course, like any design decision, you may agree with
> it or not.
As I have thought about this more, I don't think I see the need
for the "16#" and associated for this functionality to work.  If you
are using the reflective Get to the Put, that knows the base.  The
text doesn't need to specify it. If you want something more runtime
adaptive, then sure, but for pure reflective Get/Put it isn't needed
that I can tell.  In the case where a more runtime adaptive strategy
is desired, that is where I would have expected the language to want
you to roll one's own logic.