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.7 required=5.0 tests=BAYES_00,PDS_OTHER_BAD_TLD, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,e219d94b946dfc26 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!news.germany.com!news.belwue.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada.Command_Line and wildcards 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: <45dcaed8_6@news.bluewin.ch> <1172132169.423514.271890@s48g2000cws.googlegroups.com> <545bgvF1ttrphU1@mid.individual.net> <1495406.QZvfpqijrQ@linux1.krischik.com> <6dy7mn3hhu.fsf@hod.lan.m-e-leypold.de> <1172328891.5496.62.camel@localhost.localdomain> <1173096982.3712.37.camel@localhost> <8utzwzzv0v.fsf@hod.lan.m-e-leypold.de> <1173185771.11841.69.camel@localhost> <11wk29zr0.fsf@hod.lan.m-e-leypold.de> <1173305192.29628.82.camel@localhost> <1173447204.5618.131.camel@localhost.localdomain> <8g649apcio.fsf@hod.lan.m-e-leypold.de> Date: Fri, 9 Mar 2007 21:04:06 +0100 Message-ID: <9bwsz5x2uv5t.1f8tevx0wzcu4$.dlg@40tude.net> NNTP-Posting-Date: 09 Mar 2007 21:03:52 CET NNTP-Posting-Host: 1b58b327.newsspool3.arcor-online.net X-Trace: DXC=Lm5_l\YJ\<\BH3Y2\@63>n8SU:4DNcfSJ;bb[5IRnRBaCd@^lB_?FIa6?]N=WF_Kgio1 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:14438 Date: 2007-03-09T21:03:52+01:00 List-Id: On Fri, 09 Mar 2007 20:02:21 +0100, Markus E Leypold wrote: > "Dmitry A. Kazakov" writes: > >> A properly typed object named >> "fstab" would not need special "dir" to enumerate its members. > > I wanted to write "/etc", but you know, the difference is between a > _name_ and the object bound under that name. I somehow abhor the idea > of filesystems which are completely statically bound. ? The object root contains object "etc" which contains "fstab". It is not statically bound. You index a collection with a string. But wait, of course you would not need "filesystems" in a typed system of persistent objects... >>> dir "/etc/fstab" | dir_purge (fun f -> newer_than (2006,08,11) f.date ) > > is > >>> dir_purge (fun f -> newer_than (2006,08,11) f.date ) (dir "/etc/fstab" ) > > but easier to read for people thinking in sequences of transformations. I doubt it, especially because in most cases it is not a sequence but a DAG. In others it is a general case directed graph. I could also imagine purely relational interfaces to collections of persistent objects. And, there is something cranky in transformations of collections of persistent [=having identity] things. >> It already has >> these members in it. And why do you construct a new set before printing, if >> you have closures? > > What have closure to do with printing? You could do: if f.date > 2006.08.11 then f.print; end if; > And BTW, that was a mockup. There are perhaps even ways to eliminate > "print" in the toplevel, not only flatten. Flatten, BTW is sometimes > needed (because of the type system) to convert trees onto > lists. Wether I really need it in this case I haven't completely > figured out yet. You don't need to convert anything. Provide "ordered set" interface along with "DAG" interface. Or equivalently use path iterators instead of strings. Because it is supposed to be typed, the compiler will figure out what view is relevant in which case, or else complain about overloading ambiguity. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de