Q: modules + tunes-lll list?

[David Manifold]

On 8 May 1998, Basile STARYNKEVITCH wrote:

> 
> Hello All,
> 
> 2 unrelated questions regarding Tunes
> 
> 
> 1) what is a module for Tunes?
> 
> -- I understand a module as being an environment mapping name to
> values. In other words, a module is just a reified namespace. But it
> seems that some langage view module (or structures in ML) as the
> result of functors or parametrized modules.

A module is an arbitrary collection of objects, usually specified by a
human, for human use: that is to say, there is not necessarily an actual
computational dependency between the objects in the module, but they are
placed there for organization by people.

In Tunes, static definitions are equivalent to dynamic definitions, so you
could define a module as "all objects that HAD property X at the time I
put them in the module", or "all objects that have property X at the time
the module is accessed".  In the former case the module would be
statically  defined, but in the latter case a function would have to be
evaluated on-demand.  Also, you could have any range in-between, from
checking every time, to checking at interval X, or checking once at module
creation.

I hope this answers your question.

> More precisely, I believe that Tunes symbol space (symbol in LISP
> sense) are tree-like.

Yes.  They are tree-like in that there is a hierarchy of relationships.
The tree is cyclic though: some objects have many parents, and some
objects have many children.  The tree does not continuously have more
nodes as depth increases.  The reason for this is "genericity": any object
can have any property independently of any other property.  Genericity
allows us to specify objects to the level of precision needed, in both
additive properties and subtractive properties (so I can say A is X and Y
and not Z, but B is Y and Z and not X, where X=optimize for speed and
Y=bright red and Z=use garbage collection).   In this example the tree
would look like:  X  Y  Z
                  \ / \ /
                   A   B

In addition Z might be X (garbage collection optimized for speed) in which
case I'd have to draw  X       Y  
                      / \     /\
                      |  Z   /  |
                       \  \ /  /
                        \  B  /
                         \   /
                          \ /
                           A

If I added much more the lines would have to cross; in actuality the
system will be a very dense criscrossing network of dependencies that
would have a very complex diagram.  Luckily, the very
organization of such a complex structure allows us to very easily write a
mechanism for sorting through the dependencies, displaying only what we
want in the way we want it. 

> 2) why do we have two tunes mailing list. Their trafic is low enough,
> and the LLL and the rest are currently very related?
> 
> So I suggest to merge the two mailing lists into a single list.

No traffic could be a valid argument for merging lists, if the second list
had any traffic itself.  However, when both lists are dormant, doing
anything to them is a moot point.  Using your logic, there is not enough
traffic on the TUNES list to justify having a list, and yet are we going
to delete it?  No.  I think all the lists will change when the web pages
get reorganized.

[David Manifold] <dem@tunes.org>