spx - how to use another locale than base?

[John-Philip Butler]

spx runs everything in the base locale. This has served me well for years, but I am now hitting limits.
My typical workflow (95% of the time) is JHS + spx with neovim.  Virtually everything ends up in scripts for reproducibility and continuous refinement. Verbs/adverbs/conjunctions are progressively moved into libraries (application libraries, staging libraries, and reusable libraries), leaving only clear heads up functionality in the scripts.

Projects are structured with a 'lib' locale shared by all project libraries and a 'common' locale (configuration, mostly nouns).

As complexity has increased, I have moved from a single large project script divided into sections to multiple smaller 'app' scripts, each focused on a single facet. Adopting the neovim harpoon plugin (faster file switching) also contributed to this change.
I would like each app script to have its own locale, so I can switch back and forth between them in the same JHS session without worrying about name collisions.

However, spx evaluates top-level code in base, so even after:
coclass 'appX'
cocurrent 'appX'
definitions executed via spx still end up in base.

This effectively prevents using per-script locales as top-level working contexts in JHS.

Question:
Is there a way to make spx use the current locale rather than base?  or what would be a good workaround?

[Henry Rich]

Setting cocurrent changes the implied locale that will be used for future names, but it doesn't affect anything that has already been named.

I don't know spx & thus cannot answer your final question.  Can you explain what spx does that you would like to change? 

Henry Rich

To unsubscribe from this group and stop receiving emails from it, send an email to forum+un...@jsoftware.com.

[Eric Iverson]

Interesting suggestion for spx. I will need some time to think about this and am tied up right now. It will be a few weeks before I can look at this properly.

Do you have suggestions (or a working model) for how this would work?

I think labs (and stepping through scripts) are very important.

Unfortunately right now we have efforts split across the old labs (<:807), jqt style labs, and JHS spx style labs. What might work for you with spx might not work in jqt. Perhaps it is time for a push in this area.

To unsubscribe from this group and stop receiving emails from it, send an email to forum+un...@jsoftware.com.

[John-Philip Butler]

There is no rush. For the time being, i can avoid name conflicts by using discipline.

The existing behaviour of spx (i.e. ignoring locale changes) works out very well in practice, including when working with lots of objects. This allows the user to separate concerns between core J (plenty to focus on) and locale packaging; having one less thing to think of expedites exploratory work. Just being able to specify the locale in which to run the lines, with no other changes, would keep everything very simple and compositional. The exexcution context then becomes: user-chosen locale + script + line number, all of which can be specified independently of each other.

Or maybe this is just reflects my familiarity with existing behaviour, and making spx more consistent with keyboard input with respect to cocurrent would work just as well or even better.

[Devon McCormick]

If you think your smaller projects won't change much in the future, you could use explicit locale tags on their invocations, e.g. "foo_locale_" instead of "foo".

Devon McCormick

[John-Philip Butler]

My projects change on almost every run: input data mostly stays fairly constant, whereas the processing is gradually improved until the analsyis is satisfactory.