indication of erasure from outside of a locale?

[bobtherriault]

I was playing around with locales in j9.7 and came across this anomaly that I have tested back to j9.5.

'A_t_ B_t_ C_t_'=: 2 3 4
A_t_,B_t_,C_t_
2 3 4
coname ''
┌────┐
│base│
└────┘
names_t_ ''
A B C
erase names_t_ ''
1 1 1 NB. 1's indicate erasures
A_t_,B_t_,C_t_
2 3 4 NB. none have been erased
erase 'A_t_'
1 NB. 1 indicates erasure
names_t_ ''
B C NB. A_t_ has been erased
erase_t_ names_t_ ''
1 1 NB. 1's indicate erasures
names_t_ ''
NB. B_t_ and C_t_ have been erased as erase was applied in locale 't' to B and C


I am not sure why erase should indicate that it has erased when it hasn't. I understand the change in locales so that erase only sees 'A B C' as a result of names_t_ '', but shouldn't the result be 0's instead of 1's if nothing was actually erased?

A
|value error: A

B
|value error: B

C
|value error: C

erase 'A B C'
1 1 1 NB. A B and C never existed, but were erased?


Cheers, bob

[Henry Rich]

It's been that way for as long as I can remember.  I don't know why. 
4!:55 returns 1 for any valid name.

Henry Rich

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

[Gilles Kirouac]

The current behaviour is probably by similarity with APL systems
available when J was created, particularly APL2. A value of 1 indicates
that the corresponding name is now available for use. It is still so
with ⎕EX (expunge) in Dyalog APL.

~ Gilles

[Don Guinn]

What I don't like about erasing names is that it will erase a name not in the current locale, but one in its path.

[Henry Rich]

Yeah, that sucks.  I don't see a good workaround.

Henry Rich

[Raul Miller]

I do not know if anything depends on these warts in 4!:55.

If there are no serious dependencies, maybe it should be changed to
erase fully qualified names?

Otherwise, maybe we need a new erase mechanism which targets only a
single locale?

--
Raul

[Henry Rich]

4!:55 has been around 30 years.  How would you ever be confident that
you won't break old code, much of which may not have been executed for
years?

A new mechanism could be accessed in 1 of 2 ways: 4!:54 or 4!:55!.0

The new mechanism could be one of:

1. Delete only the named file, i. e. treat the search path as empty

2. Follow the search path iff the name does not contain a locative.

Henry Rich

[robert therriault]

I was wondering if we could make a change to nl so that the locale was included with the name that is returned. If you submit name_loc_ to erase then the correct erasure will take place. From what I can see the nl verb is what generates the names.

Cheers, bob

[robert therriault]

If I add one line to the definition of nl then locales will be included in the name and erase will work only on the specified locale.

nl=: 3 : 0
'' nl y
:
if. 0 e. #y do. y=. 0 1 2 3 end.
if. 1 4 8 e.~ 3!:0 y do.
nms=. (4!:1 y) -. ;: 'x y x. y.'
else.
nms=. cutopen_z_ y
end.

if. 0 e. #nms do. return. end.
if. #t=. x -. ' ' do.
'n s'=. '~*' e. t
t=. t -. '~*'
b=. t&E. &> nms
if. s do. b=. +./"1 b
else. b=. {."1 b end.
nms=. nms #~ n ~: b
end.
nms=. nms (,'_',,&'_') each coname '' NB. Added line to include locales
)

The results in action:

'A_t3_ B_t3_ C_t3_'=: 1 2 3
'A B C'=: 4 5 6
A
4
A_t3_
1
names_t3_ ''
A_t3_ B_t3_ C_t3_
names ''
A_base_ B_base_ C_base_
erase names_t3_ ''
1 1 1
names ''
A_base_ B_base_ C_base_ NB. A B C in base untouched
names_t3_ '' NB. A B C in t3 erased

Cheers, bob

[Ak]

Hi Bob,

How would your method identify a numbered Locales? Meaning, there are times we don’t know the name of the locale.

(?99)&".@>conew 'numbered_locale'

Ak

[robert therriault]

Hi Ak,

I think that it would work the same way with numbered locales. You actually do know the number of the locale as it assigned when you create it. In the following example I have already changed my standard library definition of nl to include the extra line. This means that the numbered locale has access to nl through the z locale.

t=:conew 'j' NB. create a numbered object based on the j locale
copath t NB. it has a path through j and more importantly z so it has access to nl
┌─┬─┐
│j│z│
└─┴─┘
t NB. the value of t is <,'1'
┌─┐
│1│
└─┘
'A__t B_1_ C__t'=: 2 3 4 NB. I assign values to three variables in the t locale using either name__t or name_1_ as identifiers
A_1_
2
names__t '' NB. here are the names in the t local. COCREATOR is in all numbered locales
A_1_ B_1_ C_1_ COCREATOR_1_
conames 1 NB. there is only one numbered locale t which has the value of ,'1'
1
erase names__t '' NB. erase the names in the t locale
1 1 1 1
names__t '' NB. no names left
coerase t NB. erase the locale
1
conames 1 NB. no numbered locales left

Cheers, bob

[Ak]

Hi Bob,

I might still be missing something.

If I execute this line ten times:

     (?99)&".@>conew 'numberedlocale'

I will have 10 distinct locales called 'numberedlocale'.

Each indentified uniquely by the value assigned at each call of the line.

I would need to know which instance of mylocale to call in order to use your proposal.

mylocal_numberedlocale          NB. 1. numberedlocale value -> 23

mylocal_numberedlocale          NB. 2. numberedlocale value -> 74

mylocal_numberedlocale          NB. 3. numberedlocale value -> 44

...

mylocal_numberedlocale          NB. 10. numberedlocale value -> 17

Which instance of the locale will you erase from? All of them it seems.

Ak

[robert therriault]

Hi Ak

Each time you create a numbered locale that number is the identifier of the local. Variables can be contained within that locale and they would be referenced using name__loc where name is the variable name and loc is the numbered locale in the form <,'23' for the numbered locale 23 or by name_23_ if you don't want to use the name__loc form.

My goal is to erase variables within the locale specified by the names verb.

If I erase the variables in 'numberedlocale' I should not affect the variables in any other locales at all. By identifying the locale, I am specifying the variables that will be erased.

My original concern arose from the fact that nl returns the variable names without the locales specified. That means that if you have a variable in the 'base' locale named A and a variable in the 'numberedlocale' named A you will end up erasing the A in the 'base' locale if you try erase names_'numberedlocale'_ '' . This is because names_'numberedlocale'_ '' will return the name A and then erase will revert to the 'base' local and erase that A. If the locale name is included in the result of nl (A_numberedlocale_) then erase will have the locale information needed to erase the proper variable.

The only locale that is affected is the one that you specify. In your examples, if mylocal_numberedlocale is a variable in numbered locale 23 then I would like erase names_23_ '' to erase it, but the existing version would not. It would return a 1 for every variable in names_23_ '', but would only erase variables in the 'base' locale that happened to share the same name as the ones in numbered locale 23.

Hope this is helpful.

Cheers, bob

[Don Guinn]

Wouldn't (erase__loc nl__loc '') work?

Changing the way nl works could break code that assumes that the name list is without a locale.

[Henry Rich]

I just can't see making an incompatible change to something that is so
basic unless it's wrongly specified or broken. Maybe a qualifier to nl,
but not an incompatible change.

Henry Rich

[robert therriault]

I could argue that a verb that leads to the unintended erasure of variables in the implied locale of erase is broken, but I take your point on compatibility. The following code provides the qualifier '_' for the left argument of nl.

nl=: 3 : 0
'' nl y
:
if. 0 e. #y do. y=. 0 1 2 3 end.

if. 1 4 8 e.~ 3!:0 y do.
nms=. (4!:1 y) -. ;: 'x y x. y.'
else.
nms=. cutopen_z_ y
end.

if. 0 e. #nms do. return. end.

if. #t=. x -. ' ' do.

'n s l'=. '~*_' e. t
t=. t -. '~*_'

b=. t&E. &> nms
if. s do. b=. +./"1 b
else. b=. {."1 b end.
nms=. nms #~ n ~: b

if. l do.nms=. nms (,'_',,&'_') each coname '' end.NB. Added line to include locales
end.
)

Cheers, bob

[Henry Rich]

Now you're talkin'.  Now you just have to get Chris's agreement and
update all the docs.

Henry Rich

[chris burke]

I have always regarded this as a feature, not a bug. Perhaps we should
just document it that way?

[Henry Rich]

I think the behavior of 4!:55 can be called a feature, but sometimes inconvenient. Bob's change to nl makes it less inconvenient. Shouldn't we make that compatible extension? 

Henry Rich

[chris burke]

Agreed, and the base library is updated with Bob's change.

[robert therriault]

Thanks Chris

Cheers, bob