home .. forth .. colorforth mail list archive ..

RE: [colorforth] 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: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com



---------------------------------------------------------------------
To unsubscribe, e-mail: colorforth-unsubscribe@xxxxxxxxxxxxxxxxxx
For additional commands, e-mail: colorforth-help@xxxxxxxxxxxxxxxxxx
Main web page - http://www.colorforth.com