scheme-for-max
scheme-for-max copied to clipboard
iainctduncan
[dict] with numbers as keys force string to symbol
Which gives a weird unit (symbol "1")
And I'm not sure how to deal with it in dicts with both numeric and alphabetic keys,
except very ugly workarounds which bother me for my incompetence.
Hi, can you give me more information on what you're trying and perhaps sample patch/files? thx!
Sure, thanks for responding so swiftly! Here's a sample. I'd like to use [dict] as storage for hash-tables with mixed keys.
Not that difficult to fix when keys are only numeric. I just (string->number (symbol->string key)) each key.
Now if they're mixed, the only solution I can think of is translate the keys into chars then check if any of them are members in a digit list, etc etc., then slowly rebuild them. Seems doable, but not too easy for an intermediate like me.
I could surely get by without alphabetic keys, but it would be nice to have both. Not a must though!
Ok let me see if I can understand better. Am I correct that you have a mixed key hashtable in Scheme, this is working fine, but you get an issue when saving it to a Max dict? Can you tell me where you hit the snag? Sorry it's been a while since I wrote the dict code, and to be honest, nowadays I'm just persisting things directly from Scheme! But I'd still like to make the dict integration work nicely.
The problem appears when I import any dict that has numeric keys. When it’s purely numeric, it is easily fixed. Just translate all dict keys back to string, then to number, and reconstruct the table. It gives me a hash-table that is working as intended. When it’s purely alphabetic, there’s nothing to fix, as alphabetic keys translate to symbols nicely.
But if I have a mixed dict, the solution evades me. In this case we have two types of symbols and no simple way to differentiate them. And we need to differentiate them before attempting to translate them ((string->number (symbol->string arg)) will give a wrong-type error and break the loop). And to differentiate them, we need to translate them.
(The solution I can think of is ungainly: convert string to char list, check if first element is member of a list of digits, and use that to decide if I need to translate.)
I’d gladly abandon dict if I knew how to make a file out of a hash-table!
On 2022-04-28, at 06:45, Iain Duncan @.***> wrote:
Ok let me see if I can understand better. Am I correct that you have a mixed key hashtable in Scheme, this is working fine, but you get an issue when saving it to a Max dict? Can you tell me where you hit the snag? Sorry it's been a while since I wrote the dict code, and to be honest, nowadays I'm just persisting things directly from Scheme! But I'd still like to make the dict integration work nicely.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
Seems it would require a workaround for what Max API provides.
max_atom_to_s7_obj Dict key is t_symbol. s7_make_symbol is obvious. But hash-table accepts int for key? So in the case a dict key is made up entirely of digits, I guess it should rather make an int/long key?
If Max supportslong keys natively, you could hash each Scheme object into a long, then use that long as the key in the Max dict. See e.g. sxhash in Common Lisp, or Section 13.4 "Hash functions" in the R6RS libraries.
To be clear, that would mean Scheme strings, integers, and any other Scheme type all gets hashed into a C long.