Re: Associate non-named functions to a high level group

On 2026-04-05 03:49, Heime wrote:
> On Sunday, April 5th, 2026 at 11:32 AM, Jean Louis <[email protected]> 
> wrote:
>> rcd-vc- in rcd-vc.el package and so on.
>> 
>> How about you try that way? > Jean Louis
> 
> Prefix naming schemes with multiple components have become
> too cumbersome.  I prefer tools with single-prefix names only.
> Additional associations must occur in the background, as longer
> names sacrifice the brevity of short prefixes too much.

I have 5496 functions. Having same prefix for each will not tell me 
straightforward where is that function or where it should be located.

So I keep multiple packages, like rcd-mail.el or rcd-mailing.el or 
image-stamp.el and so use different prefixes. Sometimes I have to rename 
the function in hyperscope.el instead of hyperscope- to something like 
rcd-db- which would mean that I need to put function in different file 
or package as it is more generic than package I am working in.

The more there is the more difficult it becomes.

I am even thinking of quite a different system.

I am envisioning a programming paradigm where I treat function 
definitions as strict, immutable database records rather than mutable 
named entities. In this model, each of my 5400+ functions would have a 
canonical identity (like a primary key) rather than just a name, and any 
change I make to a function's name or definition would automatically 
propagate to all other functions that reference it, maintaining 
referential integrity across my entire codebase. This would replace the 
traditional symbolic lookup system with a relational database approach 
where function dependencies are explicitly tracked and enforced, 
preventing the silent breakage that occurs when I rename a function but 
miss updating some of its callers.

In fact, automatic error verification would be one of the most powerful 
benefits of such a system.

Because every function reference is tracked as an explicit dependency 
rather than a symbolic name lookup, the database would instantly know 
when a change creates an inconsistency. Before I even attempt to run the 
code, the system could verify that every function call matches its 
target's current arity, argument types, and return signature. If I 
rename a function, the database immediately flags every caller that 
still references the old name. If I change a function's parameter count, 
the system can detect all callers passing the wrong number of arguments. 
This shifts error detection from runtime (discovering breakage when 
execution hits a specific code path) to definition-time or load-time, 
essentially giving me a continuously validating, referentially 
integrated codebase where many classes of errors become impossible to 
commit.

-- 
Jean Louis