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.1 required=5.0 tests=BAYES_00,PDS_OTHER_BAD_TLD 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 Newsgroups: comp.lang.ada Subject: Re: Ada.Command_Line and wildcards 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> <9bwsz5x2uv5t.1f8tevx0wzcu4$.dlg@40tude.net> From: Markus E Leypold Organization: N/A Date: Sat, 10 Mar 2007 11:40:20 +0100 Message-ID: User-Agent: Some cool user agent (SCUG) Cancel-Lock: sha1:dLAst2Ts0ECL23D3DfaeD+Id/d0= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 88.72.194.126 X-Trace: news.arcor-ip.de 1173522844 88.72.194.126 (10 Mar 2007 11:34:04 +0200) X-Complaints-To: abuse@arcor-ip.de Path: g2news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor-ip.de!news.arcor-ip.de!not-for-mail Xref: g2news1.google.com comp.lang.ada:14456 Date: 2007-03-10T11:40:20+01:00 List-Id: "Dmitry A. Kazakov" writes: > 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. "/etc" is a string, not an object. And I personally wouldn't want to write (fs_root.get_member "etc").get_member "fstab" > But wait, of course you would not need "filesystems" in a typed system of > persistent objects... It's my design and I'd like to keep the FS. Actually I'd want a shell not a completely different computing paradigm. > >>> 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. You know, one of the points in designing an interactive command language is, to provide syntactic sugar for the most common cases. The DAG isn't forbidden by providing alternate syntax. > 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. I didn't talk about objects. I talked about a basically functional shell. A list (e.g.) is not an object, it's just data to me. Since you're on a war footing with anything functional anyway, you might not like that approach. > >>> 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 that is supposed to be a closure? Or is that example incomplete? >> 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. Well, I should know better. > Provide "ordered set" interface along > with "DAG" interface. Thanks for teaching me how to program. But we're talking about _functional programming_ here, not OO. > Or equivalently use path iterators instead of > strings. There are no iterators in functional data. We have folds and maps and I hide them in the pipe-syntax because the idea was exactly to write down transformation steps. > 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. Overloading? There is no overloading, both with type inference (and types we want, don't we?). You completely missed most of central points of the whole idea (and you didn't even ask), but since you're not interested in it except to find you own concept in it, we can just stop discussing it. Regards -- Markus