RE: [colorforth] Re-connecting

[Frédéric DUBOIS<frederic.dubois@xxxxxxxxxxxxx>]

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

Ok, but the red light doesn't go off for me; I think there is a strong
temptation to start with unifying common fuctionnality which seems to be a
parent of the concept of factoring, and end up with generalyzing to unify. I
guess it all depends on how you achieve this unification.
But I must be misunderstanding what you mean. I've been impressed by the
work you've done in CF - so I'm inclined to trust regarding the 'what' and
the 'how'.

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

Sorry, you lost me here. I'll try to respond by elaborating my idea.
In my point of view, if the email is just text you compose it in an editor.
Then you launch your POP3 client to send this "text object" to that person
and fill-in the subject line. Maybe as intermediate step you can fetch the
email address from a database.
If your email is using a more sophisticated format - say HTML with pictures
- you still write the body of your message in your editor, then you define
the layout and include your pictures in a second app that supports HTML
WYSIWIG, and then pass the result to your POP3 client.
Of course this means that each app of this daisy chain has to provide some
mean for another app to browse it's "data object" repository.

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

Does this happen? I rarely search something in a whole (file-) system, in
particular when I know that this thing I'm looking for is in an email I
sent. To handle this, I would have the text editor to offer a
text-search-in-file capability that the mailbox app could use.
I'm a bit in trouble here. We talk about abstract "data objects" and a
would-be system and no-one has defined neither. For me, as for the system,
we are talking about a CF-like system enhanced to take advantage of a hard
disk, so you one store many applications and many data into a single mass
storage device. This means to me that a "data object" is basically a bunch
of bytes in a block.

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

Could you please give me an example of such functionnal language so I can
take a closer look at the concept?

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