Re: Ada.Command_Line and wildcards

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 09 Mar 2007 20:02:21 +0100, Markus E Leypold wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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