s: going away in next version of J

[John Baker]

I was just reading through the proposed changes in the next J 9.8 Beta and  saw that s: (symbols) are being removed from the language. I know that symbols were always a bit of hack but many of us use them. 

What is the proposed replace (the new dictionary addon) or something else?

[Henry Rich]

Yes, the Dictionary addon can map from boxed strings to integers, which is basically what s: did.

Henry Rich

On 5/29/2026 4:07 PM, John Baker wrote:

I was just reading through the proposed changes in the next J 9.8 Beta and  saw that s: (symbols) are being removed from the language. I know that symbols were always a bit of hack but many of us use them. 

What is the proposed replace (the new dictionary addon) or something else?

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

[Pascal Jasmin]

To confirm best implementation of symbols is 2 associated dictionaries, with auto-incremented integer.  have integer to boxed string as tree?  and reverse boxed string to integer as hash?

A question about valueshape/keyshape.  I can't seem to find a way to  set an x 1 shape, where boxed items would display/store as rows instead of a list of atoms.  This would also seem to impact any fixed length (limited) strings or numeric arrays as items.  Are such shapes possible?

[Henry Rich]

It should be possible to have keys that are lists, even singleton lists. 

Hold off on implementing a replacement for symbols. Making it threadsafe is a bit tricky, so i am going to enhance dicts a little to make it easier. 

Henry Rich

[Pascal Jasmin]

please delay erasing symbols until jdict is more mature.  Thank you for items function.  the comments in jdict suggest that 1 2 (16!:_8) dict could retrieve keys and values, but it crashes J.  items works fine though.

The workflow for symbol key addition into "our dictionary" is "getsert":  Just for missing boxed strings, append with maxintsofar (+ i.) count of new items into both (reversed mirror) dictionaries.  update maxintsofar with maxintsofar  + count. Then get the integers for "our keys" corresponding to the symbol/boxed strings being associated.  concurrent/threaded operation suggests that possibly not every put statement is executed before get statements that rely on the puts having been executed, are.   Even if this were guaranteed, a symbols table should not be set as concurrent to avoid multiple threads/users setting the same symbol, and replacing the associated integer to a boxed string with a new value that invalidates one thread/user's assumption.

getsert is fundamentally thread unsafe, and so symbols table cannot be set to concurrent, IMO.  Or there needs to be a "wait for all puts" synchronization call.  Another option, especially useful, for symbols or the nuvoc example dictionary is "bidirectional" unique values dictionary, where values are hashed and getv function retrieves keys.