Continue to allow all quad-variables to be defined in packages

[DavinChurch]

This arises at first when ⎕IO and ⎕ML are being set in the package. I think this is useful even when they can also be set as inherited values from the package configuration file.

First of all, I may make a mistake when setting up my configuration and it disagrees with my coded variables. Yes, I should fix the configuration to match, but until then I don't want my code to break when distributed but not break when it is being developed and tested locally. I'd rather have the confusion than failing code.

Secondly, I may have sub-namespaces that have their own (different) ⎕IO and ⎕ML and I don't want Tatin to ignore them as it creates the package, again causing it to fail.

I have these variables in my distributed-source package (GitHub, etc.) so that people obtaining and using the package directly from there (without using Tatin) will have them set properly. I don't then want Tatin to override those selections that I've already intentionally made.

[DavinChurch]

In addition, I don't want Tatin ignoring all ⎕-variables because there are many such variables which may be critical to the operation of the package. For instance, things like ⎕PP or ⎕DIV or ⎕CT or ⎕RL may be important to the code's functioning. It's important to be able to set global variables of all sorts, even the less-common ones.

[aplteam]

I am inclined to allow this though a better place to do that is in my opinion an initialization function that sets those variables when the package is loaded.

Other opinions?

[DavinChurch]

Initialization might be appropriate for use by Tatin, but packages may well be designed to run from other environments that don't provide for easy initialization procedures. My preference would be to allow alternative schemes so that sometimes (as the user prefers) packages could be used through Tatin and sometimes not. I don't seen any reason why Tatin should make it difficult for its packages to be available in other ways as well.

[aplteam]

Davin, have you considered using a class or namespace script for this?

Something like

:Namespace quadVars
⍝ The purpose of this script is to set the environment for the project.
    ##.⎕IO←1
    ##.⎕ML←1
    ##.⎕WX←3
    ##.⎕PP←120
:EndNamespace 

would work because the code is executed when the script is ⎕FIXed.

[DavinChurch]

I generally don't like using scripts of either sort if I don't have good reason to do so, and don't want to have to be forced into it for just this purpose. I'm not looking for a workaround change to the way I'm coding, just a way for normal code to be compatible with multiple situations without extra effort on either end.

If someone isn't setting specific quad-vars in their package, then they either don't care about them or they're using Tatin's definition system (or an alternative method) to control them. Therefore, I don't see any disadvantage from Tatin's viewpoint of just defining them if they're there and taking the default action if they're not (which you're assuming will be most cases). What's the harm in just defining them like everything else rather than making an exception of them?

[e9gille]

I'm not sure I understand, but if there are quad variables defined on file, Tatin should load them in. The properties in the Tatin config file were a temporary measure when it was discovered that the underlying tool (link) didn't support the quad variables on file.

[DavinChurch]

I think we've got it doing it now, but when I first posted about this it wasn't including quad variables (perhaps not even any variables) in the installed packages, even though they were in defined files when I published.

Yes, I think it's important for Tatin to support whatever was published, regardless of what might be duplicated functionality in the config file.

[aplteam]

This is not a Tatin issue, this is a Link issue.

I support the idea that Link should recognize files like ⎕PP.apla, and establish their values before anything else is brought into the workspace.

It might look like this is a Tatin issue, because Tatin is offering three system variables, but that was a temporary measure to overcome the lack of support of system variables in Link. In fact we should ridden Tatin of those values once Link is supporting ⎕SysVars.

@mkromberg @e9gille ?!

[DavinChurch]

Granted that Link does not support writing quad variables -- I think it should and I have requested this somewhere along the way. But it DOES support reading them if the files are manually created. I've got my required system var files defined in my directories and when I Link in the directory the namespace's quad-names are set appropriately.

[aplteam]

It's not enough to just read them and establish their values: it must be done before anything else is brought into the WS because scripts are going to execute code as part of ⎕FIX, and that code might well rely on certain settings.

[DavinChurch]

Ok, I guess we need to convince them to support these needs more urgently.

[DavinChurch]

Just out of curiosity, don't most scripts usually embed needed system variable settings in their files anyway?

[aplteam]

Yes, and you could well argue that they should always define their own environment, but you don't have to, so it needs to be taken care of.

[mkromberg]

Dyalog/link#380
Dyalog/link#381

I'll get this done within a few days. Having said that:

I can understand that a system might have global settings for ⎕IO, ⎕ML and ⎕WX, which are not variables that usually get changed during run-time, and can be considered part of "the source". Maybe the same is true for ⎕PP. But surely ⎕DIV and ⎕RL are things that SHOULD be localised and set within the application code.

[aplteam]

Great. Time to archive this discussion.

Why is that not possible?!

[DavinChurch]

@mkromberg, one thing I've found over the years is that what I think people SHOULD be doing is not necessarily what anybody else thinks they should be doing. So I try to allow others to make their own choices as often as I can.

In this case, I think it's reasonable to allow them to ]link.add any variable they think is important and from then on let Link use the presence of the file to keep it up to date (if that's possible).

[mkromberg]

Yup, and that is what issue 381 will do. I only added the "having said that" because I thought this was something YOU wanted to do :).

[DavinChurch]

Oh, I do, especially for the major quad-variables. But you had mentioned that ⎕DIV and ⎕RL would not be reasonable to include and I would think that all quad-variables should be included (if specifically requested), even if I don't personally need them myself.

[mkromberg]

Aha... all I meant was to say they are not reasonable to use. I can't imagine actually filtering the list - don't worry!

[mkromberg]

So... now I am confused... ]link.add and ⎕SE.Link.Add both happily allow you to add all the system variables that I tried. Did you have a problem with this? So possibly we just need to fix Dyalog/link#380. I have written the code, just need to do some testing.

[mkromberg]

I think this is all working as you would want it in Link 3.0.7 - now available on GitHub.

[aplteam]

Since there is no way to archive a discussion, or mark it as obsolete or whatever, I am going to lock this discussion.

That allows you specify is:unlocked in order to filter it out.