Re: for S'Image use Func??

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 10.05.10 18:18, Warren wrote:
> Georg Bauhaus expounded in news:4be3d4fb$0$7651$9b4e6d93
> @newsspool1.arcor-online.net:
> 
> ..
>> [1. mislead assumptions].
>> If, as Bob has said, programmers discover 'Image before
>> they discover Text_IO.*_IO and Text_IO.Editing, then there
>> is something wrong, indeed---with Ada's appearance before
>> them!  
> 
> I know all about the instantiated Text_IO stuff. The
> prevailing thing here is that I use S'Image for debugging
> a lot (saves me from also having to track down instantiated
> packages when I want to remove it). Then there's the
> lazy part of me, that wanted to capitalize on what was
> already there.

(I have "with Debugging;" in many context clauses.)

> Shoot me for those reasons. I've forgotten some Ada,
> but I'm not a newb either.

APQ is not forgotten ...  The point is that, like J.-P. Rosen
said, and like you said, 'Image is for debugging.

Since I/O is important, I guess there has to be some code
that clearly states intentions; almost necessarily this
cannot be a one liner if intentions are specific.

Can the type system help with correctly formatted
numbers? I'm not sure.  Such that construction of formatted
text strings does not have to rely on pattern substitution like
C's in printf strings etc.
C formatting patterns have been shown to be very flexible and
very dangerous. Hence extra circuits put into C compilers for
printf patterns. Python has similar pitfalls, though there
are some checks. E.g.

  if condition:
   result = "%s: bla bla %d" % (this)

This crashes your program at run time if condition == False
at compile time but becomes True at run time.


I don't buy the ``GUI = 1*String therefore just a chain
of string-producing functions'' argument (IIUC what has been
said):

- From a technical point of view, a GUI dialog is a composite
thing anyway, so construction may need to address its structure.
An object's protocol might offer guidance and checking whereas
the language cannot relate the results of string functions
to anything but strings (concatenate them). In a nest of string
functions, the programmer has full control of the strings but does
not mention the GUI item to be filled or constructed. The GUI looses,
the reader looses.  (Overloading "&" as seen needs to be done
somewhere, as seen; how can this be standardized, if at all?)

- From a design point of view, saying GUI frequently means structured
text, doesn't it?  Even forgetting that GUIs are in flux, see iPad,
much of I/O in "GUIs" is really lines of text
consisting of numbers, addresses, and phrases, possibly placed
in some table if there is enough uniformity of texts. See the Windows
mmc, the X console, Apples log views, settings, or plist editors,
TODO list management, Excel for everything, ... or some average
dialog window.
Truly graphical representations of information will be mostly non-textual.
This has yet to become mainstream in so-called GUIs, and 'Image
can't do that.

Consider writing log entries into an SQL db.  Grep is fine for logs
but an RDB lets you analyze logs with your programmer's mind
turned on.  And lets you throw log lines away systematically.  Wait.
There are tools that transfer semi-formatted log lines into
analyzable (record) structure ... :-)
So why put pieces of information into one single line of characters
with only implicit structure? (Not that I'd be doing anything else,
but it worthwhile thinking this through, it seems. :-)