RE: Re-connecting

On Wed, 23 Feb 2005, [iso-8859-1] Frédéric DUBOIS wrote:

>> Forth, with a nested vocabulary structure, can provide the basis for
>> 'attribute typed' data storage. The basic managed 'physical'
>> tree structure is
>> provided by the vocabulary nesting.
>>
>
> It looks like mixing concepts: data storage on disk, vocabularies in memory.
> Vocabularies are for words.
>
> The word "generalized" has been used above; I think this word is written on
> one of the gates of programmers' hell.

"generalized" can mean handling cases that don't occur in practice. I 
mean it in sense that common functionality is unified.

> If an application generates or act on "data objects" ( images, sound,
> traffic data, whatever ), then you use this application to manipulate these
> objects. I think it makes sense to say that this application ( or one module
> of ) should support the managment of these data objects. In Winux you launch
> your file manager, go into some subdir, click on a file and the filemanager
> reads its config files to guess what app to launch on the file. I suggest to
> launch the app first, and then the app presents you the files it has in its
> repository. No other program can present best than this app metadata on
> these objects, or sort them according appropriate criteria, at a minimal
> cost.

This idea would not go away I don't think. If I want to see my email, then 
a specialized view is more useful than a generalized view which includes 
all data objects. But consider composing an email, why should this data 
object be treated any differently than any other composition? Further, 
when it comes to searching the system, why should the contents of an email 
be treated differently then the contents of any other textual data 
object? I think this is where a unified view has great advantage over a 
system where knowledge about data objects is segregated to specialized 
applications.

> I'll go further and say that if one wants to rename, delete or copy a
> file or data object, then this also should be supported by this same app
> only because they are chances that it can do these operations in a smarter
> way than a generic filemanager would do ( for instance, if your data object
> is made of other data objects, the app could ask if you want a recursive
> delete ).
>
>
> [...]
>>
>> But for communication oriented apps, e.g. web browser or
>> email client, it
>> would probably be worth the effort to provide a rigorously defined
>> 'meta-object' format that essentially allows simple
>> replication of creation
>> time/date, modified time/date, size determination, owner
>> (hey! what _about_
>> security?).
>>
>
> I wondered if you were thinking about XML or something like that because
> from a conceptual point of veiw you're talking about some 'format' (
> langage? ) to tell things about virtually anything - but the next reference
> suggests it was just a wrong guess. Was it?

I can't speak for Terry, but XML I think is not a good example. The type 
systems of functional languages I think are a better example. Values are 
encoded efficiently, and types are sufficiently general to represent 
arbitrary data. Prolog is another example, where programs can be 
interpreted as data. In fact Datalog (a variant of Prolog) is designed for 
use as a database.

>
>> The 'meta-object' format could be self-defining, from the simplest
>> of returning 'here' to complex self-modifying data
>> structures. See Chucks
>> description of OKAD for possible implementationa of this.
>>
>
> Amicalement,
>  Frédéric
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> Main web page - http://www.colorforth.com
>
>