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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!feeder3.cambriumusenet.nl!feed.tweaknews.nl!217.73.144.44.MISMATCH!feeder.ecngs.de!ecngs!feeder2.ecngs.de!newsfeed.freenet.ag!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: for S'Image use Func?? Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <4be417b4$0$6992$9b4e6d93@newsspool4.arcor-online.net> <1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net> Date: Tue, 11 May 2010 10:26:02 +0200 Message-ID: NNTP-Posting-Date: 11 May 2010 10:26:02 CEST NNTP-Posting-Host: 2f6eb17e.newsspool1.arcor-online.net X-Trace: DXC=8U9X23D1:dPE47KDAk81NWic==]BZ:af^4Fo<]lROoRQ<`=YMgDjhgR^0\f^MK@8?Y[6LHn;2LCV^7enW;^6ZC`TIXm65S@:3>_5bXO09Q>fA_ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:11486 Date: 2010-05-11T10:26:02+02:00 List-Id: On Mon, 10 May 2010 18:50:02 +0000 (UTC), Warren wrote: > But you have no way to know when you've read > a empty line in a lexer routine that is reading > character by character. A lexer routine shall never do that. You either read lines and then parse them, or else you do stream input and the line end is to be determined by the lexer (i.e. by the language being parsed). Here is the way I do it: http://www.dmitry-kazakov.de/ada/components.htm#Parsers_etc I never had any problems with line ends. > What you end up having to do is to > test for line number changes instead-- yuk. That is because you mix encoding and language lexis. Do not mix these two and everything will become simple. > In C, that is a feature. Yes, disaster is a C feature. (:-)) > So there was a technology change. That doesn't render the > C I/O system as a "disaster". If you want to say that you > "don't like it", then I can accept that. That's different ;-) OK, it was a technology change. We do not ride horses, we drive cars. So if anybody asks me to feed a beast, clean its droppings etc, it a disaster to me, a lazy, decadent man. Yes, I know, "real programmers do not use Pascal". (:-)) >>> C of course did >>> the same thing, except that they made formatting a string >>> easier. >> >> Easier? It is untyped! > > No, no, no "said the fish as he lit to the Cat in the Hat". > > You exaggerate. It is not strongly typed like Ada, but > by George, there are "types" in C. You can think of C > differentiating on the basis of "base" types. I meant formatted I/O. That is strictly untyped, not weakly typed. If you use dynamic lists of arguments, you have to be dynamically typed or else untyped. C chose the latter. > I just cited > one common and concrete formatting instance that gets > used in C frequently, that you cannot do in Ada "out > of the box". Luckily. As others already suggested, you should use type specific operations like "&" for that. Note that C++ chose that path too. I mean the operator <<. Surely there is a better way, that is what Ada stream I/O attributes are. Unfortunately they are hard-coded, because the language lacks multiple dispatch. So if Ada needed formatted I/O, there should be similar attributes, e.g. S'Format(Output, X), S'Scan(Output). But it does not worth the efforts. >>>> I wonder why people paying so much attention to >>>> admittedly broken and misplaced formatting of Ada.Text_IO in the >>>> times of GUIs. It won't work anyway. It is not a text anymore. >>> >>> Do you enter a picture when login to your favourite GUI >>> system? A wave file for your password? We still depend >>> a lot on Text. Look at any database- it's not all about >>> blobs. >> >> No, it is, for instance, about columned output of fixed point numbers >> in proportional font aligned along the decimal point... > > And what goes into that font drawing call? Text. No, strings + lots of commands. The point is that you do not need features like alignment and filling anymore. These were issues specific for computer peripherals of 50's-80's, when formatting instructions could be encoded as ASCII characters. It does not work anymore, unless you want to mess up with PCL, HTML, PostScript, XML, which are *languages*. > Yes, you > can mess with proportional fonts if you like, but it isn't > always that way. Nobody want to see fixed font output. > In fact, there are many instances where > proportional fonts are a curse. Only if the output is improperly formatted. There is no application for fixed point fonts other than for source code of a machine language. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de