Add expression to concatenate strings

[vmorilla]

sjasmplus does not seem to allow expressions involving strings, more specifically, the concatenation.

In my case, I am trying to produce output files with a different name that depend on an environment variable to control some localization outputs. So far, I am doing something like this:

        DEFINE LANG 1
        IF LANG = 1
            DEFINE SNAFILE "build/zx_en.sna"
            DEFINE TAPFILE "build/zx_en.tap"
        ELSE
            IF LANG = 2
                DEFINE SNAFILE "build/zx_fr.sna"
                DEFINE TAPFILE "build/zx_fr.tap"
            ELSE
                DEFINE SNAFILE "build/zx_es.sna"
                DEFINE TAPFILE "build/zx_es.tap"
            ENDIF
        ENDIF 

which is quite cumbersome. Rather than that, I would like to do something like this:

Suggested solution:

        DEFINE LANG "ES"
        DEFINE SNAFILE "build/zx_" + LANG +  ".sna"
        DEFINE TAPFILE "build/zx_" + LANG + ".tap"

where '+' (or any alternative operator) produces the concatenation of two strings.

Thanks!

[ped7g]

"research" note for myself: the Lua .. concatenation operator seems to be free and low risk of clashing with other syntax.
Also Lua's # to get length of string is clashing only slightly with current syntax (#A4 is hexa number, so to get "length" operator the # would have to be followed by quotes/space/brackets I guess)

For the record, Lua syntax/priorities:

  print (#"hello")          -- 5
  print (#"he" .. "llo")    -- 2llo
  print (#("he" .. "llo"))  -- 5

And remember that string parser for DB vs SAVExxx directives is different, so ".." would have to be evaluated at least at two places (hopefully it could at least share code somehow?)

[fmafma]

I second vmorilla demand. When I have to do string concat., I make a LUA script, which is overkill in most situations.
Thanks!

[ped7g]

one more note: consider having also define substitution concatenation beyond the current _ (to make it more powerful/versatile, and offer solution for #257 ). Maybe adding _ as separate operator to concatenate during substitution phase. Need to think more about this how it could clash with current syntax, but can't recall any significance of single underscore with whitespace around in other context (could be a valid label and it is default main label in new namespace, similarly double __ could be a label)

Or maybe put the .. discussed above into substitution phase, but that's more limited than evaluation/parser operator because "ab" .. 'c' wouldn't work during substitution.

Another option is to use CPP syntax ## but that would then clash with real cpp, if somebody would decide to use it as first step before assembling. Right now the sjasmplus syntax doesn't clash with CPP syntax AFAIK and it would be probably wise to keep it like this.

I guess if the substitution operator happens, the best bet is _ and maybe document this as reserved main label name (it already kinda is) to prevent it's standalone use (it should keep working for local labels root, then the _ is followed by dot immediately).

So the old substitution rule would be nicely complemented and extended by new operator:

DEF1_DEF2       -> VAL1_VAL2      ; currently available sub-word substitution
DEF1 _ DEF2     -> VAL1VAL2       ; possible extension
DEF1 _ . _ DEF2 -> VAL1.VAL2      ; possible extension - using any character to glue two DEF values
;      ^ underscore would be invalid (but it's covered by current sybstitution syntax)
ld hl, _.local  -> ld hl, _.local ; local labels without main label currently work like this, would still work

EDIT: DG can use standalone _ denoting zero bit. So this will become somewhat ambiguous. Maybe DG can inhibit substitutions for line remainder, or _ operator can apply heuristic that at least one side of it must provide known id for substitution, but other side may be final content already. But also the priority should be lowest, ideally with everything else already substituted, so both sides will be already non-ids.. maybe mark operators early for late resolution. But it's still recursive, after resolving late _ a new id can be formed and to be substituted further.