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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,d5b211b0c1ffcf3e X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.234.38 with SMTP id ub6mr1936240pbc.2.1339668185809; Thu, 14 Jun 2012 03:03:05 -0700 (PDT) Path: l9ni49515pbj.0!nntp.google.com!news2.google.com!goblin2!goblin.stu.neva.ru!feeder2.ecngs.de!ecngs!feeder.ecngs.de!news.osn.de!diablo2.news.osn.de!news.belwue.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 14 Jun 2012 12:02:37 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Practicalities of Ada for app development References: <79c5c9f7-4b72-4990-8961-b3e2db4db79b@qz1g2000pbc.googlegroups.com> <98ef69fe-f5af-485b-89b2-9358059f4582@googlegroups.com> <92d44fa9-03ac-4f3a-84ba-4c73bf59392b@re7g2000pbc.googlegroups.com> <4bfd57a4-f220-4ab5-b649-b0d9c06db793@a16g2000vby.googlegroups.com> In-Reply-To: <4bfd57a4-f220-4ab5-b649-b0d9c06db793@a16g2000vby.googlegroups.com> Message-ID: <4fd9b6bf$0$6563$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 14 Jun 2012 12:02:39 CEST NNTP-Posting-Host: dac5c706.newsspool4.arcor-online.net X-Trace: DXC=DfPgCHS3JHiIkjb;<8iR=a4IUKjLh>_cHTX3jm9T0LTlKEm4` X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Date: 2012-06-14T12:02:39+02:00 List-Id: On 14.06.12 09:35, Ludovic Brenta wrote: > As Maciej rightly pointed out, regular expressions must be compiled > at run time (GNAT.Regexp.Compile). Before putting much emphasis on having to compile RE patterns at run-time, I suggest considering what the cost actually is, in use cases of substantial relevance. Some use cases for pattern matching: 1) [static, special] Highest possible efficiency of matching methods is desired in terms of both time and space. For example, for some FPGA, or for a program that is started and run many many times per second in limited environments. I bet there is money for funding this kind of approach in its market. Looks like it has been done. Not sure that this approach should be the goal of an Ada package for general use. 2) [source text] A convenient and effective method of specifying regular languages in source is desired, to meet the needs of ubiquitous applications. For example, finding sequences of digits in date strings to be split apart (strings from data bases, user input, documents); matching parts of URLs REs such as file name patterns, or hashed session identifiers; finding good bits in white noise. 3) [external] Regular expressions are external to the program. As is the case for configuration files, when using shells, when "programming" mail filters, etc. So, we have static, (1) specialized REs, 82) REs in source text (either static or dynamic), and (3) REs external to the program. In case 3, the program *must* be capable of compiling, or otherwise processing, the external RE. In case 2, the fraction of time spent on compiling plain REs is very likely a small fraction of the programs' running times, especially of server programs' running times. In case 1, the cost of the alternatives mentioned do not seem to be negligible at all. That is, the cost of maintaining a bulky extra parser for some regular language, or the cost of integrating a source generator that produces automata. It is worth mentioning that the source code "generator" built into C++'s template system can achieve some of the desired effects for static REs.