Re: Ada.Command_Line and wildcards

[Markus E Leypold <development-2006-8ecbb5cc8aREMOVETHIS@ANDTHATm-e-leypold.de>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> 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.

"/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