comp.lang.ada
 help / color / mirror / Atom feed
From: Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de>
Subject: Re: Array Of Constant Strings?
Date: Thu, 17 Apr 2003 20:34:13 +0000 (UTC)
Date: 2003-04-17T20:34:13+00:00	[thread overview]
Message-ID: <b7n345$91n$1@a1-hrz.uni-duisburg.de> (raw)
In-Reply-To: wccwuhtt3hb.fsf@shell01.TheWorld.com

Robert A Duff <bobduff@shell01.theworld.com> wrote:
: Georg Bauhaus <sb463ba@d2-hrz.uni-duisburg.de> writes:
: 
:> Should programming languages have string literals at all?
:> I sometimes wonder.
: 
: Heh?!

The reason is that I see many situations where a "string
literal loading mechanism" is preferable. Here are some:

- In many cases programs that do string processing get their
  strings from outside the program, not from literals in the
  program text. No string literals here.

- String literals are hopelessly scattered throughout programs.
  (They need not, but they are, for example ad hoc diagnostic
   messages.) See below.

- String literals are rarely typed (other than being a string).
  That is, string values of the same type are used in very
  different situations. That is, they defeat explicit abstraction,
  even though their content might imply the presence of abstraction.
  (Could be done with wrapper types, but is it done regularly?)

- String literals tend to follow their own non-Ada syntax.
  (Which, again, is not reflected in their type.)

- Lots of textual data can be considered data with a
  structure, but not just a sequence of characters.
  String literals don't help here.

- Often, string literals are in the way of internationalization
  (That's one reason for the mechanism called "externalising strings"
   in some IDEs.)

(All this doesn't mean I wouldn't be missing string literals for example
to quickly add some tracing output.)

Some of the strings mentiones must of course come from somewhere,
so someone must write them or say them, and some strings must
enter program text, for example in exception messages. O.K.

So, absent a "string loading mechanism", the strings could at least
be named using constants, declared in some packages that group them
together according to some predicates like for example, "this is
an error message about erroneous input".  It is much easier to
go from there to internationalisation, than if you had all the
strings scattered throughout the program. Consider a message
on a display of a teller machine, in Russian, outside Russia.
It has been a string literal in the program driving the machine...
If there were no string literals, then wouldn't you be forced to
just circumvent this deplorable incident?

It is so easy, and usual, to (mis)place string literals in
program text that people easily forget these issues. This
is why I sometimes wonder whether a programming language without
string literals is going to be an improvement.

Might there not be a causal relation between the presence of string
literals in programming languages (bad) and a templates mechanism
(Form-Letter Programming) considered a programming pearl (good)?



      reply	other threads:[~2003-04-17 20:34 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-14  2:58 Array Of Constant Strings? Dr Nancy's Sweetie
2003-02-14  4:28 ` tmoran
2003-02-14  7:28 ` Dale Stanbrough
2003-02-14  7:47   ` tmoran
2003-02-14 10:06     ` Dale Stanbrough
     [not found] ` <19guh-2f4.ln1@beastie.ix.netcom.com>
2003-02-14 19:41   ` Jeffrey Carter
2003-02-14 20:38     ` tmoran
     [not found]     ` <e0q0i-n14.ln1@beastie.ix.netcom.com>
2003-02-15 22:28       ` Jeffrey Carter
2003-02-22 19:31     ` Robert A Duff
2003-04-14 18:43       ` Dr Nancy's Sweetie
2003-04-15 11:36         ` Georg Bauhaus
2003-04-15 13:40           ` Dr Nancy's Sweetie
2003-04-15 15:13             ` Georg Bauhaus
2003-04-16  2:17               ` Matthew Heaney
2003-04-16 16:35                 ` Chad R. Meiners
2003-04-16 21:03                 ` Georg Bauhaus
2003-04-17 17:53                   ` Robert A Duff
2003-04-17 20:34                     ` Georg Bauhaus [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox