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

RE: [colorforth] Re-connecting

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


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'.
What I want might end up conflicting with what I'm willing to implement. And of course, the process of implementing can change your perspective or lead in different directions. 




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.
What came to mind when I read you original description was for instance the way mail clients today will maintain a database, and the only way to access email is through the mail client. The system may know nothing about email other than email is stored in a file in a particular location. From my point of view email is just a textual document, with some extra information like the subject, the sender, ect. A composition does not become email until it aquires essential properties like recipient, which perhaps the system will prompt for once you give the command to send your composition as an email. 

 >

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?
Yes, Google works this way and must deal with billions of data objects. How nice would it be to simply type a word or a phase and instantly access what you were looking for? Maybe it is not practical, but I would like to investigate this possibility. 


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.
Basically just bits, the meaning of those bits may be defined by the system, or a protocol. If I designate a bit sequence as a jpeg, then I don't really have to go any further, only the decoder needs to know the meaning of those bits. 


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?
OCaml is one I am familer with, and I only give it as an example, not something to emulate exactly. I think functional language of this type are an interesting study in language design. They start with a very simple model of computation, the lambda calculus, which can represent any computation. The lambda calulus has no concept of integers, lists, addition, subtraction, however all of these can be encoded as terms in the language. The encoding of integers as church numerals would be very inefficient in practice. The type systems of functional languages express the kinds of data, and the kinds of programs, the designers think are useful. And typed data can have an efficient representation, for example integer can be directly represented as a binary word. Another view of a type, is as description of the data, that is why I bring up this example in particular. Although it does not exactly correspond to the notion of a database I had in mind. 

Mark

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