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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,c689b55786a9f2bd X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!feeder.news-service.com!news.astraweb.com!border5.a.newsrouter.astraweb.com!news.netcologne.de!ramfeed1.netcologne.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Mon, 10 May 2010 19:54:25 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: for S'Image use Func?? References: <4be3d4fb$0$7651$9b4e6d93@newsspool1.arcor-online.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Message-ID: <4be84851$0$6891$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 10 May 2010 19:54:26 CEST NNTP-Posting-Host: 5fbf23be.newsspool2.arcor-online.net X-Trace: DXC=D9LTN=3aQUPmG86`U=_nC_A9EHlD;3YcR4Fo<]lROoRQ8kFZLh>_cHTX3j]PR7W6Jkl`

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. :-)