Addition of 4 new keywords and alter affected unicon code files

[brucerennie]

This commit adds 4 new keywords to Unicon:

&config - generator that returns a sequence of system configuration
values, including such things as the C Compiler used, CPU
cores, System Memory, etc. These items have been removed
from &features

&proc - returns the function value for the Unicon function proc()

&parent - currently fails. Will be used to return the parent of the
current thread

&child - generator that returns all threads created by the current
thread

The keyword &features generator now only returns the sequence of runtime features.

The source files affected are:

./src/runtime/keyword.r - holds the implementation of the above keywords.
./src/icont/keyword.h - holds the relevant #defines for each of the
available keywords defined in [keyword.r].
This file is auto-generated by running the
Unicon file [mkkwd.icn] after the defines are
removed from this file.
./src/h/kdefs.h - holds the macro definitions associated for
each of the keywords defined in [keyword.r].
This file is auto-generated by running the
Unicon file [mkkwd.icn] after the defines are
removed from this file.

Other files that have been updated to now use the new keyword [&config] instead of the keyword [&features] are:

./ipl/procs/io.icn - change reference from &features to &config
./ipl/procs/paths.icn - change reference from &features to &config
./uni/ide/ui.icn - change reference from &features to &config
./uni/udb/srcfile.icn - change reference from &features to &config
./uni/unicon/unicon.icn - change reference from &features to &config
./uni/unicon/unigram.y - to include new keywords in keyword list
./uni/unicon/unigram.icn - to include new keywords in keyword list
./uni/unicon/unigram.u - to include new keywords in leyword list

File updated with new Version number 13.4

./config/scripts/version.sh - update 13.3 to 13.4, this flows throughout
the rest of the system after running autoconf
./configure - updated to current version 13.4

[brucerennie]

Jafar,

the only issue that has arisen is the creation of a Debian package, otherwise it builds on all systems,

[cjeffery]

There has been much past e-mail discussion about keyword &features having a design bug, being unbounded as to how many features we might add, and thus becoming arbitrarily slower to check as the number of results grows longer and longer. Addressing an O(n) problem by splitting it into two O(n/2) problems isn't a super solution, as O(n/2) is O(n).

I have no problem with &proc although it "fixes" a problem that is not a real problem.

I have agreed to add &parent although doing so seems like it should wait until the keyword is implemented. My main reservation about it is that "parent" is not a term exclusive to threads; for example in other contexts it refers to programs. Awkward.

I have agreed to add &child.

Although it makes sense to bundle several keyword changes in a single PR, these keywords are complex, some are not implemented yet, etc. Removing behavior from &features would not be OK EXCEPT in the case of newer &features that haven't been documented or used much yet. If one can credibly assert that no programs would break, then maybe. Many of the &features being stolen to put in &config are newer and I can live with "moving" them to a new home at &config, just not very excited about it being another generator.

[StephenWampler]

Oh, got it.  &parent is the thread that *created* the current thread, not which thread last activated it.  What are the proposed uses for &parent and &child?  I think I can come for a use for &parent (or whatever it ends up being named) and maybe &child (use it to activate all the children coexprs instead of maintaining an explicit list of them) but I can see that being a potential risk (maybe the current thread has children that do different things and activating all of them through a keyword would produce undesirable behavior) but I'm personally more comfortable with keeping my own lists of child coexprs organized into functional groups.

…

On 10/3/25 09:56, Bruce Rennie wrote: &parent - currently fails. Will be used to return the parent of the current thread

-- Steve Wampler - ***@***.*** The gods that smiled at your birth are now laughing out loud - fortune cookie

[Jafaral]

There has been much past e-mail discussion about keyword &features having a design bug, being unbounded as to how many features we might add, and thus becoming arbitrarily slower to check as the number of results grows longer and longer. Addressing an O(n) problem by splitting it into two O(n/2) problems isn't a super solution, as O(n/2) is O(n).

While performance is a concern, I don't think that was the driving factor why we started thinking about a new keyword. &features is a language features. Memory, number of CPUs, C compiler, etc, have nothing to do with language features. Those are environment attributes, or just external meta data.

I have agreed to add &parent although doing so seems like it should wait until the keyword is implemented. My main reservation about it is that "parent" is not a term exclusive to threads; for example in other contexts it refers to programs. Awkward.
We don't have to merge this until all keywords are all implemented. I can easily add commits to this branch once Bruce says it is ready and I can add the implementation before we merge the PR.

I have agreed to add &child.

"parent" and "child" can be used in different contexts and not specific to threads. Thought they are popular in thread programming. We looked at alternatives before, not sure alternatives would be better. We could use "&ancestor" instead of "&parent". Similarly, we can use "&descendant", "&spawned", or "&worker" instead of "&parent".
in fact , I feel like "&ancestor"/&descendant would work fine in thread context.

Although it makes sense to bundle several keyword changes in a single PR, these keywords are complex, some are not implemented yet, etc. Removing behavior from &features would not be OK EXCEPT in the case of newer &features that haven't been documented or used much yet. If one can credibly assert that no programs would break, then maybe. Many of the &features being stolen to put in &config are newer and I can live with "moving" them to a new home at &config, just not very excited about it being another generator.

Even if we have &config, I think a few of those would still be provided under &features for backward compatibility. Some of those re used mostly by internal libraries and we can fix those. We can poll the people on the mailing list. Something like Binaries at should always be available under &features, because it has been there for a long time, even if we make also available under &config.