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-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!postnews.google.com!r9g2000vbk.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: for S'Image use Func?? Date: Sat, 15 May 2010 13:50:47 -0700 (PDT) Organization: http://groups.google.com Message-ID: <66e2a4b1-2784-4c60-8e6a-2237c7f7b477@r9g2000vbk.googlegroups.com> References: <1qcb6z4i20dyb.1dz2hd4c0vx69.dlg@40tude.net> <87632vwikr.fsf@ludovic-brenta.org> <112n6z3554srr$.tjzjtg467xfo.dlg@40tude.net> <1fv8frriu1h4s.g9jy78q1c0io.dlg@40tude.net> <7a31eab7-1a1c-4653-bf49-ff1498e318f9@b18g2000yqb.googlegroups.com> <199e07cb-2e93-40fc-974d-000b83b6000f@s29g2000yqd.googlegroups.com> <16vlvmzpbalm5.1chuumyyuyb2j$.dlg@40tude.net> <1fe63c27-207f-4a73-a823-3ec1410e35e8@j35g2000yqm.googlegroups.com> <1g82ubkc0t0pf$.nuj3gqp1buh6.dlg@40tude.net> <5715ce4b-3ddc-4f50-8b4d-094e93db657a@e21g2000vbl.googlegroups.com> <1o1jj8ho00vti.18z26rwdv3apb.dlg@40tude.net> NNTP-Posting-Host: 85.222.87.69 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: posting.google.com 1273956647 9693 127.0.0.1 (15 May 2010 20:50:47 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 15 May 2010 20:50:47 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: r9g2000vbk.googlegroups.com; posting-host=85.222.87.69; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3,gzip(gfe) Xref: g2news2.google.com comp.lang.ada:11648 Date: 2010-05-15T13:50:47-07:00 List-Id: On 15 Maj, 10:35, "Dmitry A. Kazakov" wrote: > Do you want to say that text files are Turing complete? (:-)) Maybe they > are. Maybe they are not. Consider an experiment. Let us generate random > files containing CRs, LFs and other characters. Show the file to several > people asking them to count lines... Wrong, unless you clearly define the meaning of "show". People do not have the ability to consume files in their storage form. The file has to be *rendered* somehow to be accessible to our senses. For example, it has to be *displayed*, for example using a text editor or a web browser - and this is when the whole exercise becomes both trivial and pointless. And if you give me the freedom to choose my rendering scheme, it will be: $ cat -n file.txt > >>> So what is a text, really? > > >> It is not a book. > > > A scientific paper, perhaps? Or a CV? > > A memo, minutes etc. Wrong. I happen to attend meetings which are so long and rich, that their minutes deserve structure. > > If you stick to the concept of "text" as defined by Text_IO > > (completely unstructured sequence of lines), then effectively the only > > use-case that you will cover without problems is... config files. > > + source codes, which nicely covers 90% of my tasks. Fine. You still forgot about log files. :-) > I don't need Ada.Document_IO. Me neither. I'm perfectly OK with the stream I/O. > > The C++ source code is not a text for me. > > Then you shall not use text editors with it. I don't. I use programmer's editors, also known as IDEs, with it. > >>> Translation: Text_IO cannot detect the end of text without blocking. > > >> No, the translation is: stream does not have an end. > > > That's your arbitrary definition and you did not provide any reference > > for it. > > It does not mean that no stream may have it. It is only a negation that > every stream does. I did not say that every stream has an end. I said that Ada.Text_IO cannot discover it without blocking. Whether the stream has an end or not is completely irrelevant to my original statement, but since you decided to mix it into the discussion... > Anyway, if you tried to define the stream end, you could not do in terms of > its elements, You will need some "non-functional," "out-of-band" return > codes, exceptions etc. Yes. > Blocking is just among others. No. Blocking is not a statement about stream. It tells me nothing about the stream and it still blocks my program. It is a useless strategy and not intuitive, as it shows that the stream is being physically consumed as part of what is a purely predicative operation. > You could say: it > ends when blocked. Not very nice, but, in fact, widely used in network > communication protocols. Widely? An example or two, please? -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4