pkg.m status and question

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

pkg.m status and question

PhilipNienhuis
Hi,

The last weeks I've been poking around in pkg.m, not so much for fun but
rather for fixing issues that I felt were in my way. (Other users &
developers seemed to have lived with it for years now). Along the way I
received several comments that pkg.m and private helper functions constitute
an unduly complicated beast. Explicitly or implicitly it emerged that the
conceived complexity is a big motive to stay as far away from pkg.m as
possible.
IMO the complexity largely mimics the way add-on packages are implemented:
local and global packages; standardized locations or separate locations for
.m files and/or binary modules; don't get me started about package
dependencies. On top of that I have the impression that some OF packages
themselves have a complicated setup that must somehow be accommodated in
Octave's package structure; either Octave's package structure is too limited
or those packages are just too complicated, I don't know.
But I can agree with comments that the code could be improved.

At this moment  I just have a question, mainly aimed at the previous
developers of pkg.m, about a very practical point:

The octave_packages file(-s, local and global) are just .mat files. The
setup is a cell array and each cell contains a scalar struct for each
package.
==> Question: why is it a cell array of scalar structs in the first place?
Why not a regular struct array?

The only reasons I can come up are these:
* That way each package can have a struct with dedicated fields when some
package requires so.
* It was always that way, perhaps by technical constraints in times gone by
and no one bothered.

My motive for asking is that this setup of package info makes for needlessly
inefficient and complicated code. For each tiny action the relevant structs
have to be unwrapped first. IMO dealing with a struct array rather than cell
array of structs would make the code much more transparent and much more
efficient as well.

Any thoughts?

Thanks,
Philip






--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

Mike Miller-4
On Mon, Jan 06, 2020 at 04:26:21 -0600, PhilipNienhuis wrote:
> My motive for asking is that this setup of package info makes for needlessly
> inefficient and complicated code. For each tiny action the relevant structs
> have to be unwrapped first. IMO dealing with a struct array rather than cell
> array of structs would make the code much more transparent and much more
> efficient as well.

I agree with this motivation, having seen this before too. I can't speak
to why it was originally done as a cell array of scalar structs.

I do have a speculation. The current design reads each pkg DESCRIPTION
file into a scalar struct, which is then added to a cell array of all
pkgs. A problem arises if you have pkg A which has a "Url" field in its
DESCRIPTION, and pkg B which has a "SystemRequirements" field in its
DESCRIPTION. How do you easily combine two structs with unlike fields
into a single struct array with a superset of all fields?

By way of example,

    a.Name = "first";
    a.Description = "A package";
    a.Url = "https://www.example.org/";
    b.Name = "second";
    b.Description = "Another package";
    b.SystemRequirements = "fftw3";
    all = [a, b];

doesn't work. But the current cell array implementation does.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

Juan Pablo Carbajal-2
>     a.Name = "first";
>     a.Description = "A package";
>     a.Url = "https://www.example.org/";
>     b.Name = "second";
>     b.Description = "Another package";
>     b.SystemRequirements = "fftw3";
>     all = [a, b];
>
> doesn't work. But the current cell array implementation does.

Int he direction of making pkg handling better, we should have a
uniform structure for the DESC file with all possible fields, any DESC
file that does not fill one leaves the default value of NA.
A few advantages:
1. the structs of each package is uniform
2. any functions parsing this struct knows what fileds to expect and
how to handle them
3. the struct itself is a description of the DESC file (automatic pkg
generation or future pkgcreator)
4. the DESC file can be documented on the code that generates this
struct, that is, an extension to the manual entry.

Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

PhilipNienhuis
In reply to this post by Mike Miller-4
Mike Miller wrote:

> On Mon, Jan 06, 2020 at 04:26:21 -0600, PhilipNienhuis wrote:
>> My motive for asking is that this setup of package info makes for needlessly
>> inefficient and complicated code. For each tiny action the relevant structs
>> have to be unwrapped first. IMO dealing with a struct array rather than cell
>> array of structs would make the code much more transparent and much more
>> efficient as well.
>
> I agree with this motivation, having seen this before too. I can't speak
> to why it was originally done as a cell array of scalar structs.
>
> I do have a speculation. The current design reads each pkg DESCRIPTION
> file into a scalar struct, which is then added to a cell array of all
> pkgs. A problem arises if you have pkg A which has a "Url" field in its
> DESCRIPTION, and pkg B which has a "SystemRequirements" field in its
> DESCRIPTION. How do you easily combine two structs with unlike fields
> into a single struct array with a superset of all fields?
>
> By way of example,
>
>     a.Name = "first";
>     a.Description = "A package";
>     a.Url = "https://www.example.org/";
>     b.Name = "second";
>     b.Description = "Another package";
>     b.SystemRequirements = "fftw3";
>     all = [a, b];
>
> doesn't work. But the current cell array implementation does.

Thanks Mike, that's one thing I figured (and mentioned as first reason).
But I'm not so impressed. At my work we have complete input data sets
for our groundwater models in nested Matlab structs (some up to 100's of
MBytes on disk in compressed v7.3 format, in perhaps 5-10 nesting
levels); such heterogeneity as you mention is vital and a feature we
have quite a bit of experience with.

Probably too much detail now, but here goes:
We need a basic struct with all required fields that are of the same
type for all packages.
All fields that are heterogeneous (not required for each package and/or
not used by the package manager) go in substructs or cell arrays in a
dedicated field of the main struct. That way we move heterogeneity from
the outside wrapper into a much less prominent location inside, out of
the way of regular package manager operations.
Upgrading an old package database to a new format can be done with a
dedicated function; such a function can't be too complicated and as it
runs just twice (global and local) doesn't need much optimization (read:
developer time). Maybe that function sniffs what the database looks like
and acts if it's the old cell type. Saving and reading the package
database is otherwise unaffected.
When installing a new package a check could be due for new fields in the
"Description" substruct/cell array. Maybe it isn't even necessary.

But read on, another step is needed as well:

Carné rightly mentions backward compatibility. I surmise that is because
the global octave_packages file by default lives in the share/octave/
directory, and as a consequence it is shared between octave releases
(and theoretically between OS-es if it served to e.g., remote clients).
(Even the local octave-packages file is/can be shared between Octave
releases, but I ignore that for now.)
IMO that is a wrong place to begin with as octave_packages has "hard"
references to arch-dependent subdirs as well; each package in the
package database has just one reference to an arch-dependent subdir.
That implies that OF packages with binary modules cannot be shared
reliably between Octave releases anyway (I've been bitten very often by
that). Nor can packages be shared between different OS-es. It can be
argued that even the arch-independent directory cannot be shared between
Octave releases as .m-files can invoke functions or constructs that are
new or dropped or renamed in different releases.
All in all, IMO a somewhat better place for the package database would
be in share/octave/<release>/ and the packages themselves as well.
Or am I wrong? please enlighten me then.

That said, I wonder how much practical situations exist where OF
packages are shared between Octave releases on networks, or even clients
with different OS-es.

My impression is that here's a quite a bit of legacy in the way,
hindering simplification of package management.

Philip

Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

Mike Miller-4
In reply to this post by Juan Pablo Carbajal-2
On Mon, Jan 06, 2020 at 23:34:06 +0100, Juan Pablo Carbajal wrote:
> Int he direction of making pkg handling better, we should have a
> uniform structure for the DESC file with all possible fields, any DESC
> file that does not fill one leaves the default value of NA.

I humbly suggest that the package description struct should have some
number of required fields, but any number of user-defined optional
fields that can be added to the package as needed. There is no way to
define all possible fields. That's the way it works now, please don't
make it more restrictive.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

Mike Miller-4
In reply to this post by PhilipNienhuis
On Mon, Jan 06, 2020 at 23:44:24 +0100, Philip Nienhuis wrote:
> We need a basic struct with all required fields that are of the same type
> for all packages.
> All fields that are heterogeneous (not required for each package and/or not
> used by the package manager) go in substructs or cell arrays in a dedicated
> field of the main struct. That way we move heterogeneity from the outside
> wrapper into a much less prominent location inside, out of the way of
> regular package manager operations.

This seems unnecessarily awkward for the task at hand. Are you
suggesting a package description struct might be accessed like this

    d = pkg ("list", "foo")
    d.name
    d.version
    d.maintainer
    d.extensions
    d.extensions.citation
    d.extensions.wiki
    d.extensions.("bug-tracker")

or like this

    for i = 1:length (d.optionalfields)
      d.optionalfields{i}.keyword
      d.optionalfields{i}.value
    endfor

Does it really seem like a worthwhile tradeoff to introduce a new nested
struct or array of optional properties just to have a fixed base
structure definition that can be stored in an array? No, that seems even
more complicated to me. This is software, after all, not a packet
protocol.

I guess internally you can store it however you feel is best, but the
user should have access to an easy flat structure that contains all of
the package metadata, both required and optional, as it is now.

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

Juan Pablo Carbajal-2
In reply to this post by Mike Miller-4
> On Mon, Jan 06, 2020 at 23:34:06 +0100, Juan Pablo Carbajal wrote:
> > Int he direction of making pkg handling better, we should have a
> > uniform structure for the DESC file with all possible fields, any DESC
> > file that does not fill one leaves the default value of NA.
>
> I humbly suggest that the package description struct should have some
> number of required fields, but any number of user-defined optional
> fields that can be added to the package as needed. There is no way to
> define all possible fields. That's the way it works now, please don't
> make it more restrictive.

If user can add arbitrary fields, then there is no standard.
My proposition is that we manage to get this flexible enough that if
new fileds are good ideas, the stadard can be extended.
We can also always have a "UserDefined" field in the basic structure
that collects all user define fields that are not part of the
standard. This goes close to the idea of Philip.

Functions that process this information need to process the standard
fields, but can do whatever they wish with th einfo inside
"UsedDefined".
This gives a lot of uniformity in the code, and probably the
identification of lots of boiler plate sections and good practises.

my two cents

Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

PhilipNienhuis
In reply to this post by Mike Miller-4
Mike Miller wrote:

> On Mon, Jan 06, 2020 at 23:44:24 +0100, Philip Nienhuis wrote:
>> We need a basic struct with all required fields that are of the same type
>> for all packages.
>> All fields that are heterogeneous (not required for each package and/or not
>> used by the package manager) go in substructs or cell arrays in a dedicated
>> field of the main struct. That way we move heterogeneity from the outside
>> wrapper into a much less prominent location inside, out of the way of
>> regular package manager operations.
>
> This seems unnecessarily awkward for the task at hand. Are you
> suggesting a package description struct might be accessed like this
>
>      d = pkg ("list", "foo")
>      d.name
>      d.version
>      d.maintainer
>      d.extensions
>      d.extensions.citation
>      d.extensions.wiki
>      d.extensions.("bug-tracker")
>
> or like this
>
>      for i = 1:length (d.optionalfields)
>        d.optionalfields{i}.keyword
>        d.optionalfields{i}.value
>      endfor
>
> Does it really seem like a worthwhile tradeoff to introduce a new nested
> struct or array of optional properties just to have a fixed base
> structure definition that can be stored in an array? No, that seems even
> more complicated to me. This is software, after all, not a packet
> protocol.
 >
 > I guess internally you can store it however you feel is best, but the
 > user should have access to an easy flat structure that contains all of
 > the package metadata, both required and optional, as it is now.

I suppose that you refer to the output of the pkg.m function, not so
much the contents of the octave_packages files, right?  AFAIU the latter
aren't meant to be edited so can be v7 formats as well and their
internal setup shouldn't matter to the average user.

Did you look at e.g., 'out = pkg ("describe")'?
The result is another seemingly (to me) needlessly complicated
datastructure: a cell array of structs, each of such a struct again
containing some fields comprising cell arrays of structs.
E.g., a small part of the zeromq entry of above command's output in my
mxe-octave installation:

:
   [1,48] =
     scalar structure containing the fields:
       name = zeromq
       version = 1.5.0
       description = ZeroMQ bindings for GNU Octave
       depends =
       {
         [1,1] =
           scalar structure containing the fields:
             package = octave
             operator = >=
             version = 4.0.0
       }
       provides =
       {
         [1,1] =
           scalar structure containing the fields:
             category = ZeroMQ overview
             functions =
             {
               [1,1] = zeromq
             }
:
:

Your wish to keep a flat data structure triggers my curiosity: what is
the use case of having a flat output structure? Why is that needed?
IMO any user who needs to access pkg.m's output should be proficient
enough to grasp nested data structure.

Anyway, no fear, I'm not planning to start hacking deeply into pkg.m
soon. I'm just investigating, ATM just out of curiosity.

When and if the time comes it's easy to leave the output package info
cellstructs as they are and add translation routines from a
programmatically more manageable data struct.

Philip

Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

Rik-4
In reply to this post by PhilipNienhuis
On 01/07/2020 09:00 AM, [hidden email] wrote:
Subject:
Re: pkg.m status and question
From:
Juan Pablo Carbajal [hidden email]
Date:
01/07/2020 02:24 AM
To:
Mike Miller [hidden email]
CC:
Maintainers GNU Octave [hidden email]
List-Post:
[hidden email]
Precedence:
list
MIME-Version:
1.0
References:
[hidden email] [hidden email] [hidden email] [hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
Content-Type:
text/plain; charset="UTF-8"
Message:
3

On Mon, Jan 06, 2020 at 23:34:06 +0100, Juan Pablo Carbajal wrote:
Int he direction of making pkg handling better, we should have a
uniform structure for the DESC file with all possible fields, any DESC
file that does not fill one leaves the default value of NA.
I humbly suggest that the package description struct should have some
number of required fields, but any number of user-defined optional
fields that can be added to the package as needed. There is no way to
define all possible fields. That's the way it works now, please don't
make it more restrictive.
If user can add arbitrary fields, then there is no standard.
My proposition is that we manage to get this flexible enough that if
new fileds are good ideas, the stadard can be extended.
We can also always have a "UserDefined" field in the basic structure
that collects all user define fields that are not part of the
standard. This goes close to the idea of Philip.

Functions that process this information need to process the standard
fields, but can do whatever they wish with th einfo inside
"UsedDefined".
This gives a lot of uniformity in the code, and probably the
identification of lots of boiler plate sections and good practises.

my two cents
I'm sensitive to Mike's original argument.  The future is hard to predict, and deciding today on the number, name, and type of fields that will exist for all time is too difficult.  In some manner, the architecture must support change.  I am agnostic as to whether that flexibility is because each struct lives alone as a cell element, or because there is a modifiable "UserDefined" field.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

Mike Miller-4
In reply to this post by PhilipNienhuis
On Tue, Jan 07, 2020 at 18:18:01 +0100, Philip Nienhuis wrote:
> I suppose that you refer to the output of the pkg.m function, not so much
> the contents of the octave_packages files, right?

Yeah, I am only talking about the user interface of the "pkg" function,
not any internal details.

The existence and format of the "octave_packages" file is an entirely
internal technical detail. In fact, it's easy to imagine a "pkg"
implementation that doesn't have this file at all.

> Did you look at e.g., 'out = pkg ("describe")'?
> The result is another seemingly (to me) needlessly complicated
> datastructure: a cell array of structs, each of such a struct again
> containing some fields comprising cell arrays of structs.

Sure, the "depends" and "provides" fields are complex, but I think it's
somewhat necessary, since other "pkg" commands parse that information. I
think both of those fields could be more easily converted to ordinary
struct arrays, since these contents do have fixed formats.

> Your wish to keep a flat data structure triggers my curiosity: what is the
> use case of having a flat output structure? Why is that needed?

My use case is for simple package metadata lookups to be as simple as
possible. I maintain the Pythonic package on GitLab. I want it to be
very easy for a novice user to get URLs such as the git repository, the
issues page, the user manual, and the wiki from a "pkg" command. For
example

    pyinfo = pkg ("list", "pythonic");
    web (pyinfo.url)
    web (pyinfo.issues)
    web (pyinfo.wiki)
    system (['git clone ' pyinfo.repo]);

This would work today, though with a '{1}' added on the "pkg" command,
ideally that can go away.

> IMO any user who needs to access pkg.m's output should be proficient enough
> to grasp nested data structure.

I disagree, I think the output is part of the user interface, and as
such it should be designed to be as clear, simple, and useful to all
users as possible. If it's not clear, simple, and useful, then why
return it at all?

The overall direction I want to see is for packages and package
repositories to become more flexible, and for the packaging commands to
facilitate that flexibility.

Ultimately, I would like to see packaging commands that help users
install packages from external web, git, or hg hosting sites, update
those packages automatically, point their web browser at the docs,
switch to a development snapshot and back to the latest release, and so
on.

IMHO, a big part of that is allowing package maintainers to add their
own metadata to the DESCRIPTION and providing easy access to those
metadata, to experiment with well before they become standardized.

Thanks for your interest,

--
mike

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

PhilipNienhuis
Mike Miller wrote:
> On Tue, Jan 07, 2020 at 18:18:01 +0100, Philip Nienhuis wrote:
>> I suppose that you refer to the output of the pkg.m function, not so much
>> the contents of the octave_packages files, right?
>
> Yeah, I am only talking about the user interface of the "pkg" function,
> not any internal details.

<snip>

>> Your wish to keep a flat data structure triggers my curiosity: what is the
>> use case of having a flat output structure? Why is that needed?
>
> My use case is for simple package metadata lookups to be as simple as
> possible. I maintain the Pythonic package on GitLab. I want it to be
> very easy for a novice user to get URLs such as the git repository, the
> issues page, the user manual, and the wiki from a "pkg" command. For
> example
>
>      pyinfo = pkg ("list", "pythonic");
>      web (pyinfo.url)
>      web (pyinfo.issues)
>      web (pyinfo.wiki)
>      system (['git clone ' pyinfo.repo]);
>
> This would work today, though with a '{1}' added on the "pkg" command,
> ideally that can go away.

So pyinfo needs a cell rather than a struct array, right?

Anyway, that use case seems valid enough for me :-) Thanks for that
information.
I myself never use pkg.m's output args so this info helps quite a bit.

>> IMO any user who needs to access pkg.m's output should be proficient enough
>> to grasp nested data structure.
>
> I disagree, I think the output is part of the user interface, and as
> such it should be designed to be as clear, simple, and useful to all
> users as possible. If it's not clear, simple, and useful, then why
> return it at all?

With me that immediately raises the question of why "pkg describe"
returns such horrible (but complete) output. Who/what uses it?

> The overall direction I want to see is for packages and package
> repositories to become more flexible, and for the packaging commands to
> facilitate that flexibility.
>
> Ultimately, I would like to see packaging commands that help users
> install packages from external web, git, or hg hosting sites, update
> those packages automatically, point their web browser at the docs,
> switch to a development snapshot and back to the latest release, and so
> on.
>
> IMHO, a big part of that is allowing package maintainers to add their
> own metadata to the DESCRIPTION and providing easy access to those
> metadata, to experiment with well before they become standardized.

Thanks for this, it gives some welcome grip on what people want from pkg.m.

In comment #18 of bug #57522 I wrote something that may help:
Try to do away with the package databases. All info is already in the
DESCRIPTION files in the PACKINFO subdirs, and loading states are in the
path. Generating required info for pkg.m operations can be done on the
fly and there is less chance for it to be outdated. Parsing and
validating the DESCRIPTION file into programmatically more manageable
bits and pieces in PACKINFO/ would facilitate this.

Philip

Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

Juan Pablo Carbajal-2
In reply to this post by Rik-4
> I'm sensitive to Mike's original argument.  The future is hard to predict, and deciding today on the number, name, and type of fields that will exist for all time is too difficult.  In some manner, the architecture must support change.  I am agnostic as to whether that flexibility is because each struct lives alone as a cell element, or because there is a modifiable "UserDefined" field.

Predicting the future here has no role. the point is that you need to
define a standard for your package distribution and management system.
Goals of the standard:
1. Easy to extend (here are all your concerns about the future
covered, there is no attempt to predcit the future [1], but to be able
to adapt to it)
2. Uniform and stable. The uniformity allows us to produce code that
anybody can use for they packages (if the follow the standard). The
stability is just a desire to avoid too much maintenance

Hence, the DESC fiel should have standard (required) fiels (it has
already), and the user can add more arbitrary fields, but those will
be parsed inot a uniform field (that is always present in the program
representation of the DESC file (e.g. a structure)) which could be
called "UserDefined". Standard code will not parse that field, but the
user's functions can use it in the context of their packages.

I do not think we have a differnet opinon here, but it seems you are
opposing to something in my proposal that I cannot pin-down.

[1] It is funny that you guys are worried about the future, because in
another discussion (regarding pkg unload) you prefer to not allow the
user to unload packages at will, essentialy **assuming that in the
future there is no usecase for that** (despite that fact that a use
casewas already offered). so not prediciting the future would be to
let the user unload the way the want, and if you do not like a
particular way, just warn about it.

Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

PhilipNienhuis
In reply to this post by Juan Pablo Carbajal-2
Juan Pablo Carbajal-2 wrote

>> On Mon, Jan 06, 2020 at 23:34:06 +0100, Juan Pablo Carbajal wrote:
>> > Int he direction of making pkg handling better, we should have a
>> > uniform structure for the DESC file with all possible fields, any DESC
>> > file that does not fill one leaves the default value of NA.
>>
>> I humbly suggest that the package description struct should have some
>> number of required fields, but any number of user-defined optional
>> fields that can be added to the package as needed. There is no way to
>> define all possible fields. That's the way it works now, please don't
>> make it more restrictive.
>
> If user can add arbitrary fields, then there is no standard.
> My proposition is that we manage to get this flexible enough that if
> new fileds are good ideas, the stadard can be extended.
> We can also always have a "UserDefined" field in the basic structure
> that collects all user define fields that are not part of the
> standard. This goes close to the idea of Philip.
>
> Functions that process this information need to process the standard
> fields, but can do whatever they wish with th einfo inside
> "UsedDefined".
> This gives a lot of uniformity in the code, and probably the
> identification of lots of boiler plate sections and good practises.

FYI
It turns out that the only fields that are really used for pkg.m operations
(viz. un-/installing, un-/loading) are "name", "release", "depends", "dir"
and "archdir".
All other fields are only parsed from the DESCRIPTION file and put into the
package's cellstruct item and they are returned verbatim in case of "pkg
describe" and "pkg list".

Philip




--
Sent from: https://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

Re: pkg.m status and question

Rik-4
In reply to this post by Juan Pablo Carbajal-2
On 01/10/2020 02:51 AM, Juan Pablo Carbajal wrote:

>> I'm sensitive to Mike's original argument.  The future is hard to predict, and deciding today on the number, name, and type of fields that will exist for all time is too difficult.  In some manner, the architecture must support change.  I am agnostic as to whether that flexibility is because each struct lives alone as a cell element, or because there is a modifiable "UserDefined" field.
> Predicting the future here has no role. the point is that you need to
> define a standard for your package distribution and management system.
> Goals of the standard:
> 1. Easy to extend (here are all your concerns about the future
> covered, there is no attempt to predcit the future [1], but to be able
> to adapt to it)
> 2. Uniform and stable. The uniformity allows us to produce code that
> anybody can use for they packages (if the follow the standard). The
> stability is just a desire to avoid too much maintenance
>
> Hence, the DESC fiel should have standard (required) fiels (it has
> already), and the user can add more arbitrary fields, but those will
> be parsed inot a uniform field (that is always present in the program
> representation of the DESC file (e.g. a structure)) which could be
> called "UserDefined". Standard code will not parse that field, but the
> user's functions can use it in the context of their packages.
>
> I do not think we have a differnet opinon here, but it seems you are
> opposing to something in my proposal that I cannot pin-down.

I think you may be arguing with someone else.  I only wrote one e-mail on
the subject which was the one you quoted.  As I remarked, I don't care
about the actual implementation (cell array, DESC file, etc.) as long as
the software architecture chosen is flexible rather than brittle.  A
current example of the trend from another area of computer science is
databases, where programmers are moving away from the fixed schema of
relational databases and implementing NoSQL dabatases instead.
 
>
> [1] It is funny that you guys are worried about the future,

I'm not one of "you guys" whoever they are.  I haven't been following this
thread except for the one general comment I made.

--Rik